Date: Thu, 18 Sep 1997 18:06:51 +0200 (SAT) From: Graham Wheeler <gram@cdsec.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709181606.SAA00506@cdsec.com> In-Reply-To: <7198.874597557@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 05:45:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >This is a preliminary report, as it is still very early and the results > >we are seeing may be coincidental. > > >I'll follow up on this in the morning (South African time) - if the > >process is still running smoothly this would suggests that there > >may be a problem with the malloc/free code in libc. > > Well, you'll still have to do more to convince me. I'll do my best... ;-) > The fact that two malloc implementations act differently is no proof > of one of them being wrong, the different policies they use can make > a bit difference in the outcome for errors in the main code. Agreed. > > Imagine this: > > char *p = malloc(12); > char *q = malloc(12); > p[12] = 'B'; > > In the case of phkmalloc you have written into padding space, > in the case of many other mallocs you have just destroyed the > "back" pointer for the *q allocation. The results are very > different. The debug libmalloc that I am now using uses the following layout for an allocated block: | prevlink | nextlink | size | memspace | size | 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, > Another very common mistake is to trust the storage returned to > contain zero bytes. I certainly don't assume this. I am very careful to either memset the allocated memory to zero if necessary, or, in the case of C++ objects, to explicitly initialise every member variable in the constructor. These are lessons learnt long ago after much pain and suffering... > Try the following 3 experiments: > > 1 set the 'A' flag to phkmalloc. > > 2 set the 'J' flag to phkmalloc. > > 3 set the 'Z' flag to phkmalloc. > > If they are any different in behaviour, they your code has a > problem. I tried all of these already a couple of days back. They made no difference. > Remember to keep fd#2 open to a logfile. Doing so. 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). -- 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?199709181606.SAA00506>