From owner-freebsd-stable@FreeBSD.ORG Mon Apr 7 06:25:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5597F106566C; Mon, 7 Apr 2008 06:25:37 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoot.lafn.org (zoot.lafn.ORG [206.117.18.6]) by mx1.freebsd.org (Postfix) with ESMTP id CF3E38FC14; Mon, 7 Apr 2008 06:25:36 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.2] (pool-71-109-162-173.lsanca.dsl-w.verizon.net [71.109.162.173]) (authenticated bits=0) by zoot.lafn.org (8.13.6/8.13.4) with ESMTP id m376PY1U073966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 Apr 2008 23:25:35 -0700 (PDT) (envelope-from bc979@lafn.org) Message-Id: <3554B945-7E75-448E-9BCF-977E9B9955C3@lafn.org> From: Doug Hardie To: Jeremy Chadwick In-Reply-To: <20080407053849.GA85535@eos.sc1.parodius.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 6 Apr 2008 23:25:34 -0700 References: <1794897B-7A36-412A-8849-87F10268EBAE@lafn.org> <20080406214524.GA72199@eos.sc1.parodius.com> <20080406215237.GA72336@eos.sc1.parodius.com> <20080407005444.GB77472@eos.sc1.parodius.com> <48EED2B2-CB92-4907-A70B-9E86566F4EF3@lafn.org> <20080407053849.GA85535@eos.sc1.parodius.com> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV 0.88.7/6644/Sun Apr 6 22:18:13 2008 on zoot.lafn.org X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: getenv in FreeBSD 7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 06:25:37 -0000 On Apr 6, 2008, at 22:38, Jeremy Chadwick wrote: > On Sun, Apr 06, 2008 at 08:18:20PM -0700, Doug Hardie wrote: >> On Apr 6, 2008, at 17:54, Jeremy Chadwick wrote: >>> On Sun, Apr 06, 2008 at 03:05:18PM -0700, Doug Hardie wrote: >>>> >>>> On Apr 6, 2008, at 14:52, Jeremy Chadwick wrote: >>>>> On Sun, Apr 06, 2008 at 02:45:24PM -0700, Jeremy Chadwick wrote: >>>>>> On Sun, Apr 06, 2008 at 02:37:06PM -0700, Doug Hardie wrote: >>>>>>> Somewhere between FreeBSD 6.2 and 7.0 getenv has been changed to >>>>>>> return >>>>>>> a >>>>>>> null if an environment variable is set but has no value. I >>>>>>> don't find >>>>>>> anything anywhere in the documentation/man pages on this. As a >>>>>>> result, >>>>>>> you >>>>>>> cannot distinguish between a variable that is not set and one >>>>>>> that is >>>>>>> set >>>>>>> to a value of "". Is this a bug or a feature change? >>>>>> >>>>>> I'd begin peeking here: >>>>>> >>>>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/ >>>>>> getenv.c >>>>> >>>>> Follow-up: the manpages between 6.3-PRERELEASE and 7.0-STABLE do >>>>> document said change: >>>>> >>>>> http://www.freebsd.org/cgi/man.cgi?query=getenv&apropos=0&sektion=3&manpath=FreeBSD+6.3-RELEASE&format=html >>>> >>>> Says that if the environment variable is NOT IN THE ENVIRONMENT >>>> then null >>>> is returned. Setting the variable to "" does put it in the >>>> environment. >>>> env returns it properly. >>>> >>>>> >>>>> >>>>> http://www.freebsd.org/cgi/man.cgi?query=getenv&apropos=0&sektion=3&manpath=FreeBSD+7.0-stable&format=html >>>> >>>> Same thing. I find nothing documented about this change. >>> >>> I'm not sure where you're going with this. I see it clearly in the >>> ERRORS section. >> >> I didn't think that having a defined variable with the value "" >> would be an >> error. getenv does not return EINVAL but returns a zero. I would >> have >> expected some notification in the description of getenv. > > My apologies: I misread the manpage. The ERRORS section applies to > setenv(), putenv(), and unsetenv() -- not getenv(). So ignore my > earlier claims about EINVAL being relevant to getenv(). > > getenv() will either return a pointer to what the environment variable > contains (and if empty (e.g. ""), it should stil return a pointer to a > buffer that consists of nothing but NULL), or if getenv() returns NULL > then it means the variable isn't set. earlier today I definitely saw 0x0 returned for several hours. Broke a bunch of my code. One was in a core dump, the others were in gdb. Now its not doing that. > > >>> But besides that, just like Bakul Shah, I cannot reproduce this >>> problem: >>> >>> $ uname -mr >>> 7.0-STABLE amd64 >>> $ gcc -o z z.c >>> $ ./z >>> getenv(FOO) = (null) >>> $ export FOO=yep >>> $ ./z >>> getenv(FOO) = yep >>> export FOO= >>> $ ./z >>> getenv(FOO) = >>> $ cat z.c >>> #include >>> #include >>> >>> int main(void) >>> { >>> char *e = getenv("FOO"); >>> >>> printf("getenv(FOO) = %s\n", e); >>> return 0; >>> } >> >> At this time, it does return a pointer to "". However, earlier >> today it >> did not. It returned a zero. It was quite consistent for several >> hours. >> I wonder if this is another issue with gdb. It seems to be quite >> flakey on >> 7.0. > > I'd expect there to be an immense amount of "random breakage" in all > sorts of scripts on a system, ditto with Apache spawning CGIs which > rely > on environment variables (REMOTE_ADDR comes to mind), if getenv() was > unreliable. The ports system, for example, relies heavily upon > environment variables. I have been relying on environment variables since 2.5. Never had an issue till now. While I do have heavily loaded servers that heavily use them, this paticular server is very lightly loaded and rarely uses them. > > > As I was writing this, I was thinking if a local resource starvation > issue could cause this (libc being unable to malloc some memory > without > a proper failure check, or stack space running out), but after looking > at getenv() and related functions, I don't see how this could be > possible. > > The next time it happens, post here with some more details. > Definitely > a mysterious one... I agree. I suspect though that it might be related to gdb. I can't explain the first core dump, but I have encountered enough bugs with gdb that I have no problems with it being the cause.