From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 28 18:10:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EEC716A416 for ; Wed, 28 Jun 2006 18:10:58 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id D583143F4E for ; Wed, 28 Jun 2006 18:10:48 +0000 (GMT) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k5SIAlJG030555 for ; Wed, 28 Jun 2006 20:10:47 +0200 Received: from ims.mchp.siemens.de (ims.mchp.siemens.de [139.25.31.39]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k5SIAkSk017219 for ; Wed, 28 Jun 2006 20:10:46 +0200 Received: from mail-ct.mchp.siemens.de (mail-ct.mchp.siemens.de [139.25.31.51]) by ims.mchp.siemens.de with ESMTP id k5SIAkJQ011935 for ; Wed, 28 Jun 2006 20:10:46 +0200 (MEST) Received: from curry.mchp.siemens.de (curry [139.25.40.130]) by mail-ct.mchp.siemens.de (8.12.11/8.12.11) with ESMTP id k5SIAkuH020665 for ; Wed, 28 Jun 2006 20:10:46 +0200 (MEST) Received: (from localhost) by curry.mchp.siemens.de (8.13.6/8.13.6) id k5SIAjn2050907; Date: Wed, 28 Jun 2006 20:10:45 +0200 From: Andre Albsmeier To: freebsd-hackers@freebsd.org Message-ID: <20060628181045.GA54915@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.11 Cc: Andre.Albsmeier@siemens.com Subject: Return value of malloc(0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 18:10:58 -0000 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... -Andre P.S.: If someone wants to know where the crash happens in firefox please see http://bugzilla.mozdev.org/show_bug.cgi?id=13809.