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>