Date: Thu, 18 Sep 1997 18:40:57 +0200 (SAT) From: Graham Wheeler <gram@cdsec.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: gram@gram.cdsec.com (Graham Wheeler), hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709181640.SAA00548@cdsec.com> In-Reply-To: <10531.874599844@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 06:24:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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'. > >Can you offer an explanation as to why the process never returns from > >the call to malloc, nor does it abort? This seems to indicate an infinite > >loop. Not having delved too deeply into your code, I can only speculate > >that the linked list is being made circular, so the process is in an > >infinite, looping traversal. Perhaps that is a check that can be added; > >namely that walking the list must always proceed forward, never backward > >(assuming that the list is kept in sequential order). It is interesting to note that this looping is almost always what happens - it is very rare that the process actually aborts. It seems strange that the bahaviour is so consistent, especially as the stack backtraces are in very different parts of my own code, and the application itself is pretty non-deterministic, being I/O event-driven. This, together with the fact that 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... > 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 ;-). > 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... 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. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709181640.SAA00548>