Date: Thu, 18 Sep 1997 21:05:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709182105.OAA12918@usr03.primenet.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
> >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). > > 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). > > 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. You could also get this after a free followed by another malloc for a shorter amount, and another malloc, with code using the original freed pointer. This could blow the list in either direction. Freeing something, making anohter overlapping allocation, and then freeing the original something again could do it too. Humorously, this is exactly the kind of thing you would get when you passed something allocated in thread local storage from thread A to B, and then thread A exits before thread B uses the pointer. 8-). I have suggested for some time now that allocations be ended against page boundries: A page: ,-------------------------------------------------------.,------ | xxx*************************||////// `-------------------------------------------------------'`------ Key: xxx malloc housekeeping *** user area /// guard page (unmapped) The result of any overruns would be a trappable and localizable fault. It is usedful to consider a "hole-y" stack for the same reasons; This would not necessarily require huge modifications to the compiler, on a "call-on-user-stack" mechanism for functions; for a whole-code environment, tiny compiler modifications are all that's necessary (so you push the arguments on the new stack before the call, mostly). The result of this would also be trappable and localizable faults for references of too many variables in the absence of a prototype to flag the error, and overrun of user arrays. If you wanted to go whole-hog, you *could* put each variable against it's guard page. Alternately, you could put all data in a referral area, and take a fault on each data access. The resoloution of the fault condition would check scope (effectively giving you byte level memory protection) and then return the referral area. Or signalling an error. Etc.. At least some of these are trivial to implement; you may want to consider it... Poul was right in his other posting about malloc() implementations showing programmer errors in different, unanticipated ways. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709182105.OAA12918>