malloc free debugging
Asmund Ostvold
Jeg er med på å lage et C bibliotek og noen av de som bruker
biblioteket bruker biblioteket feil. For å lette support jobben mot
disse har jeg behov for å vite størrelsen på minne som blir frigitt
når det gjørs free(&x) av programmet.
Det er ikke noe problem og lage en free_hook men jeg trenger er måte
og få størrelsen på det minne som blir frigitt. Er det noen her som
har gjort dette før eller har ideer hvor jeg kan finne eksempler på
hvordan det har gjort dette før.
Jeg kan lage min egen malloc_hook og lage datastrukturer som kan
fortell meg dette men jeg hadde håp om å slippe dette.
På forhånd takk.
Åsmund
Bjørn Brox
Det kommer helt an på maskin og operativsystem, men engang i tida da jeg
sleit med tilsvarende problemer på ett solaris system så fant jeg ut at
størrelsen ligger lagret som en long sizeof(long) bak pekeren (hvis du
skjønner hva jeg mener).
free(void *ptr) {
...
long size = *((long *)(((unsigned char *)ptr) - sizeof(long))))
eller noe slikt.
Uansett: Hvis feilen som du antyder ligger i at det er ikke-gyldige
pekere som sendes til free() så er du like langt.
Ellers: Hvilket OS programmerer du under?
Idag så finnes det jo en mengde verktøy og debuggere som kan overvåke
minnebruk/misbruk og som dermed kan gi deg gode svar på hva som gjøres feil.
--
Bjørn Brox
Kjetil Torgrim Homme
>
> Jeg er med på å lage et C bibliotek og noen av de som bruker
> biblioteket bruker biblioteket feil. For å lette support jobben
> mot disse har jeg behov for å vite størrelsen på minne som blir
> frigitt når det gjørs free(&x) av programmet.
>
> Det er ikke noe problem og lage en free_hook men jeg trenger er
> måte og få størrelsen på det minne som blir frigitt. Er det noen
> her som har gjort dette før eller har ideer hvor jeg kan finne
> eksempler på hvordan det har gjort dette før.
beklagar, men dette kan endre seg utan varsel i ein
malloc-implementasjon, og eg trur ikkje det er nokon god idé å
forutsetje noko som helst. (jf. Solaris der ein kan velje mellom tre
implementasjonar ved køyring.)
viss du kan relinke applikasjonen, så er Electric Fence og dmalloc to
alternativ. viss du køyrer dette på Linux på x86 maskiner, er
valgrind eit fint verkty.
--
Kjetil T.
Asmund Ostvold
[ Bjørn Brox ]
> Det kommer helt an på maskin og operativsystem, men engang i tida da jeg
> sleit med tilsvarende problemer på ett solaris system så fant jeg ut at
> størrelsen ligger lagret som en long sizeof(long) bak pekeren (hvis du
> skjønner hva jeg mener).
> free(void *ptr) {
> ...
> long size = *((long *)(((unsigned char *)ptr) - sizeof(long))))
>
> eller noe slikt.
Jeg har fått dette forklart også men jeg er interessert i en løsning
som er mer varig en denne.
> Uansett: Hvis feilen som du antyder ligger i at det er ikke-gyldige
> pekere som sendes til free() så er du like langt.
Det er ikke pekeren til free som er feil det er feil og slette pekeren
på dette tidspunktet. (se pseudo kode lenger ned).
> Ellers: Hvilket OS programmerer du under?
OS er Linux men jeg hadde et håp om at det var løsning som ville
fungere på andre OS også.
> Idag så finnes det jo en mengde verktøy og debuggere som kan overvåke
> minnebruk/misbruk og som dermed kan gi deg gode svar på hva som gjøres feil.
Det er ikke direkte misbruk som er problemet mitt. Jeg kan lage et
lite eksempel som forklarer problemet:
------
....
foo = malloc(x);
.
.
.
Ber bibliotek om og bruke deler minne foo peker på. Biblioteket
returnerer før man er ferdig med å bruke minnet.
.
.
.
free(foo); <- dette er feil før neste linje er kalt
.
.
.
Kalle funksjon i biblioteket som ikke returnerer ikke før man er
ferdig med bruke av minnet.
...
------
Det jeg vil er under "debugging" ha en funksjon som kjøres når free()
kjøres. Det denne funksjonen trenger x fra foo. Fordi jeg da kan
sjekke mot interne strukturer i biblioteket at minne ikke er i ikke er
i bruke av biblioteket.
[ Kjetil Torgrim Homme ]
> beklagar, men dette kan endre seg utan varsel i ein
> malloc-implementasjon, og eg trur ikkje det er nokon god idé å
> forutsetje noko som helst. (jf. Solaris der ein kan velje mellom tre
> implementasjonar ved køyring.)
En løsning er å lage en hook for malloc som lager en tabell som har
peker og størrelse. Dette kan legges i et bibliotek som preloades når
man ønsker å debugge programmet for denne type feil.
> viss du kan relinke applikasjonen, så er Electric Fence og dmalloc to
> alternativ. viss du køyrer dette på Linux på x86 maskiner, er
> valgrind eit fint verkty.
Jeg kan ikke relinke men jeg kan preloade applikasjonen. Jeg tror
ikke Electric Fence løser denne problematikken. Jeg har sett litt på
dmalloc og så ikke funksjonaliteten jeg ville ha. Jeg skal ta en titt
på valgrind.
Hvis noen har noen hint så ser jeg fortsatt etter en løsning.
Aasmund