Date: Mon, 15 Oct 2001 18:37:25 -0600 (MDT) From: Heath Nielson <heath@cs.byu.edu> To: David Marker <marker_d@yahoo.com> Cc: <freebsd-stable@FreeBSD.ORG> Subject: setenv() cores with NULL value [was Re: Gdm proplem on 4.4] Message-ID: <Pine.LNX.4.33.0110151727300.6035-100000@organ.cs.byu.edu> In-Reply-To: <20011015170857.68722.qmail@web14702.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Oct 2001, David Marker wrote:
> I have installed FreeBSD 4.4 from downloaded ISO
> images. I finally got everything just the way
> I like it, but gdm did not work, the following
> command brought up X but not gdmlogin:
> # /usr/X11R6/bin/gdm -nodaemon
>
> When I check with "ps", I find that one of gdm's
> child processes is using over 90% of the CPU. So I
> ran ktrace to find out what gdm is doing. Turns
> out not to be very helpful because the PID that
> runs away calls stat() gets a good return and then
> never call another system call again.
>
> I attached gdb to it to investigate and found
> gdm is stuck in setenv() which surprises me.
> I look at /usr/src/lib/libc/stdlib/setenv.c
> and am surprised more. In fact since its chewing
> up most of my cpu I thought gdm must be in a
> tight while loop.
>
> The disassemly does not show that, it consistently
> shows gdm is stopped on a comparison. Specifically
> gdb showed gdm was trying to compare (%eax) to 0x3d
> (which turns out to be the '=' ASCII character).
>
> If you look at setenv.c the line that pops out
> given this disassembly is:
> if (*value == '=')
>
> Unfortunately I only had my ISO images and no
> access to gdm source. But I did modify libc to
> to find out the name that is trying to be set
> which causes the problem: "GDM_TIMED_LOGIN_OK".
> It calls it with a NULL pointer for value.
> No matter how you change gdm.conf setenv() is
> called for GDM_TIMED_LOGIN_OK with a NULL pointer
> for value.
>
> So there are a few issues:
> gdm should not be calling setenv() with
> value = NULL (possibly the GTK library
> should catch this).
>
> when gdm does call setenv improperly, the
> kernel should send gdm a SIGSEGV and gdm
> should dump core.
While I don't know if gdm should be setting a NULL value or not, I ran
this simple program:
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char* argv[])
{
char* name = "TEST";
char* value = NULL;
int ret;
printf("value: %s\n", value);
ret = setenv(name, value, 1);
printf("ret: %d\n", ret);
return 0;
}
On FreeBSD I get:
hershey:~$ ./a.out
value: (null)
Segmentation fault (core dumped)
On Linux:
catskill 23: ./a.out
value: (null)
ret: 0
FreeBSD doesn't like a NULL value. There was no mention of NULL input
values in the man page. It seems that a NULL value is valid. I can type
export TEST= at the prompt without any errors, but I'm no shell expert.
Maybe the TEST env. variable's value isn't really NULL. Does anyone else
have anything to add to this?
> I don't think the signal was blocked, ktrace
> never shows it being sent!
>
> In a way this sounds related to the 8 January
> post "SIGSEGV can be blocked!?".
>
> You can work around this by changing setenv() in
> libc to check if value is NULL and return if it
> is (which is what I'm doing). But I think setenv()
> is doing the right thing and a core should be
> produced. The real solutions are in the kernel and
> gdm (or possibly GTK).
>
> Thanks
> -dave
>
Heath
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0110151727300.6035-100000>