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 <stdio.h>
#include <stdlib.h>
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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
