Date: Thu, 18 Sep 1997 19:09:20 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Graham Wheeler <gram@cdsec.com> Cc: gram@gram.cdsec.com.dk.tfs.com (Graham Wheeler), hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <10666.874602560@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 18 Sep 1997 18:40:57 %2B0200." <199709181640.SAA00548@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199709181640.SAA00548@cdsec.com>, Graham Wheeler writes: >Howdy > >> >i.e. the size is stored both immediately preceding and immediately >> >following the useable space. As part of the consistency checking, >> >these two sizes are compared and should match. This should catch almost >> >all small overruns or underruns, and abort the process. So this >> >malloc should be less tolerant of bugs in my code than pkhmalloc is, >> >rather than more tolerant, >> >> again: depends. > >Fair enough - I assume then that the reason your prior example had padding >was because you round allocations up to multiples of four bytes, rather >than always adding padding to be `fault-tolerant'. Slightly more complicated, all allocations less than 2048 are rounded up to nearest power of two, minimum 16 bytes. Allocations above 2048 are rounded up to an integral number of pages (4k). >the problem only started when we moved to from FreeBSD 2.1 to 2.2.2, >is why I suggested that the bug may be in the malloc code. Let me state >quite clearly though that this is a suggestion, certainly not an accusation. >I'm just running out of things to suspect... I'm not taking it as such, don't worry :-) It's just that my work on phkmalloc has taught me far more about how subtle malloc related problems can manifest themselves, and I now realize why Purify costs what it does. If I'd written it, I wouldn't charge any less. >> This is about the only way you could get it to loop I think. That means >> that somebody wrote to memory malloc hadn't passed them (ie: your code). > >Well, someone's code ;-). sure :-) But this is the first report I have of such a loop. :-) >> This would indicate a bug of the class where memory is written to after >> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > >Nor should it, that would be a performance sacrifice. That's why I linked >with a debug library. > >I'll check once again for this, but doubt I'll find anything - I'm quite >meticulous about zeroing pointers after freeing them, unless the variable in >question goes out of scope immediately afterwards. I *have* to meticulous - >I'm the person who gets the flack when things go wrong, and believe me, you >don't want 5000 pissed off people screaming at you that they can't surf the >web... Know the feeling. >If the process is still running fine tomorrow morning, I am going to try >a version linked with the alternative libmalloc but using the non-debug >version; this could also be interesting. Consider trying mprof-3.0 and boehm-gc maybe one of them will find it. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10666.874602560>