Malloc og free

Tags:    c

Hej udviklere.

Skal til et projekt selv udarbejde en malloc og en free funktion til en del at et styresystem. Der er stillet nogle bestemte krav til opgaven, men her er hvad jeg har lavet indtil videre. Det har virket i en mindre version af styresystemet, men det virker ikke længere. Resten af systemet bruger uint64_t, men hele mit system crasher. Kan i umiddelbart opdage en fejl i min linked list?



Fold kodeboks ind/udC kode 

Mvh



10 svar postet i denne tråd vises herunder
1 indlæg har modtaget i alt 1 karma
Sorter efter stemmer Sorter efter dato
Jeg hapsede lidt ud af headeren...mangler stadig værdien af 'headerSize'. Er det sizeof(struct Node) ?

Mit testprogram er faktisk ikke så vildt. Det udfører en række tilfældige allokeringer, deallokeringer og reallokeringer og udskriver inden noget C kode, som ville gøre det samme. F.eks.:
Fold kodeboks ind/udC kode 


Hvis programmet crasher, så udskrives en epilogue:
Fold kodeboks ind/udC kode 


Resultatet bliver koden til et program, som udfører de samme skridt, som førte til en SIGSEGV.



Indlæg senest redigeret d. 05.05.2014 13:29 af Bruger #2695
Bob bob...hvilket styresystem?

Du har to variable kaldet *available_physical_memory. Har du virkelig adgang til fysisk hukommelse?

I Linux fungerer malloc ved at kontrollere hukommelsen op til systemets break (brk()). Har malloc selv brug for mere hukommelse, så flyttes break. For store allokeringer bruges mmap.

Jeg ser intet sted, hvor du beder styresystemet om mere hukommelse (som f.eks. ved et kald til sbrk()/mmap(). Er det måske derfor? Man kan jo under normale omstændigheder ikke bare bruge løs af hele adresserummet uden at mappe den pågældende hukommelse.



True. Vi kører styresystemet på en virtuel maskine, hvor *available_physical_memory, kun referere til starten på et stort array.



Ok, så burde den del jo virke. Kan jeg få dig til at poste lidt mere kode?
Header og så'n, så jeg kan compile, og også gerne et test program. Jeg lavede selv en malloc/free implementering engang og brugte følgende program til at teste den:

Fold kodeboks ind/udC kode 


Jeg kan så køre det i en løkke indtil det fejler og pipe dets output til en C fil. Når det fejler har jeg en testcase, som jeg kan debugge på. Noget i stil med:
Fold kodeboks ind/udKode 


Det vil udskrive antallet af gennemkørsler af programmet. Når løkken stopper kan jeg bare compile "fail.c" og køre det i en debugger. Det fangede jeg en del fejl på, men nu finder det ikke flere.



Indlæg senest redigeret d. 05.05.2014 12:53 af Bruger #2695
wow, det ser rimelig vildt ud, og nok lidt over mit niveau.

min header fil ser sådan her ud
Fold kodeboks ind/udC kode 
og er en del at det større system, så det er ikke sikker det giver mening.

Mvh



I see. Det var faktisk en opgave vi havde tidligere på semesteret, og der virkede mine funktioner. Der var et testprogram, som allokerede og free'ede nogle tilfældige størrelse.

i den nye udgave, som jeg satte ind tidligere, er headersize:
Fold kodeboks ind/udC kode 



I den tidligere version, hvor det virkede, havde jeg dog mulighed for at bruge int istedet for uint64_t.

Mvh



Hmm...så headerSize bliver mindre (halvt så stor), når du går fra 32 til 64 bit. Kan det være rigtigt?
Jeg ville have forventet en fordobling.



Det er et krav i opgaven, at memory blokke bliver "aligned on a 32 byte basis".



Men jeg kan se, at headerSize bruges til mere end bare alignment...f.eks. denne:
Fold kodeboks ind/udKode 


På en 32 bit maskine bliver det til:
Fold kodeboks ind/udKode 


..og på en 64 bit maskine er det:
Fold kodeboks ind/udKode 


Hvis der er en header i starten af blokken, og du vil springe over den, så giver det jo ikke mening at headeren bliver mindre, når pointerne bliver større.



Indlæg senest redigeret d. 05.05.2014 14:03 af Bruger #2695
I styresystemet, bliver 64_bit kernel portet til 32 bit kernel. Vi har også fået nogle test-programmer som kalder hinanden og blot udskriver noget på skærmen. Hvis jeg hardcoder
allocationStart = *available_physical_memory, kan den køre første program, men da den så kalder næste crasher alt.
:/



t