Date: Wed, 28 Jun 2006 23:29:57 +0200 From: Stefan Farfeleder <stefan@fafoe.narf.at> To: Andre Albsmeier <Andre.Albsmeier@siemens.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Return value of malloc(0) Message-ID: <20060628212956.GI822@wombat.fafoe.narf.at> In-Reply-To: <20060628181045.GA54915@curry.mchp.siemens.de> References: <20060628181045.GA54915@curry.mchp.siemens.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: > There is a nice extension for firefox called prefbar. However, > newer versions of prefbar (>=3.3) make firefox die with SIGSEGV, > see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details. > The crash happens in libgklayout.so: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1 (LWP 100116)] > 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at > nsGlobalWindow.cpp:6378 > 6378 timeout->mArgv[timeout->mArgc] = > Current language: auto; currently c++ > (gdb) p timeout->mArgc > $1 = 0 > (gdb) p timeout->mArgv > $2 = (jsval *) 0x800 > (gdb) p timeout->mArgv[timeout->mArgc] > Error accessing memory address 0x800: Bad address. > > The 0x800 are the result of an earlier malloc(0). When looking > at the MALLOC(3) manpage, we can read (near the description of > the flags): > > ... > V Attempting to allocate zero bytes will return a NULL pointer > instead of a valid pointer. (The default behavior is to make a > minimal allocation and return a pointer to it.) This option is > provided for System V compatibility. This option is incompatible > with the ``X'' option. > ... > > > So I gave it a try by running > > MALLOC_OPTIONS=V firefox > > and firefox didn't crash anymore and prefbar was running :-). > (Now malloc returns NULL and firefox doesn't interpret the > result as a pointer to some allocated memory and therefore > doesn't use it). > > The manpage makes me think that when malloc is called with 0 > as argument (and no V-flag had been set) the pointer it returns > can actually be used (as a pointer to the so-called "minimal > allocation"). It seems, that firefox "thinks" the same way :-). > However, it is calculated in malloc.c as a constant and is > always 0x800 (on my architecture). Any access to this area > results in a SIGSEV. > > I assume the behaviour is meant to show up programming errors: > > "If you use malloc(0) and are crazy enough to access the 'allocated' > memory we give you a SIGSEV to show you how dumb you are :-)". > > In this case the manpage is wrong (or, at least, mis-leading) and > should be fixed (I could give it a try if someone actually is willing > to commit it). > Apart from that, I suggest, we should run firefox (and maybe other > mozilla apps) with MALLOC_OPTIONS=V. > > Another position could be that firefox is wrong because it NEVER > may use ANY return value of a malloc(0), regardless of its content. > > Opinions, please... The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. I agree that the wording in the man page should be improved. Probably it should say that malloc(0) returns a non-NULL pointer which must not be dereferenced without mentioning a "minimal allocation". Stefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060628212956.GI822>