It happens when something is changed to /etc/gdm/gdm.conf-custom. Is there an easy way to get a backtrace of the crash? Setting the debug to "true"  prints:
"...
Handling user message: 'GET_CONFIG greeter/MinimalUID=100'
mainloop_sig_callback: Got signal 17
..."

Created attachment 57276 [details]
Default Ubuntu configuration

The bug happen with the default Ubuntu gdm.conf but not with the default upstream one. I'm attaching the configuration in case you have an idea of what option could trigger that

I notice a few hacky things in teh default gdm.conf file that would likely make GDM mad, though I'm not sure how it works at all.

1) You have DefaultPath set like this:

   DefaultPath=DefaultPath=/usr/local/bin:...

   I would think that this wouldn't work at all.  It should be just

   DefaultPath=/usr/local/bin:...

2) You have Greeter set to /usr/lib/gdm/gdmgreeter.  Is that right on Ubuntu
   or should it be /usr/lib/gdmgreeter?

Does the problem happen for just the "GET_CONFIG greeter/MinimalUID=100" option or does debug show that other config options are successfully retrieved before it tries loading this one?

Does commenting out the MinimalUid configuration value in gdm.conf make a difference?

(In reply to comment #3)

>    DefaultPath=DefaultPath=/usr/local/bin:...
> 
>    I would think that this wouldn't work at all.  It should be just
> 
>    DefaultPath=/usr/local/bin:...

Right, I've spoted that this morning while reading the diff between the upstream and 
Ubuntu configs, fixing it doesn't change that issue


> 2) You have Greeter set to /usr/lib/gdm/gdmgreeter.  Is that right on Ubuntu
>    or should it be /usr/lib/gdmgreeter?

It's the right place, we install binaries to /usr/lib/<package> 


> Does the problem happen for just the "GET_CONFIG greeter/MinimalUID=100" option
> or does debug show that other config options are successfully retrieved before
> it tries loading this one?

The log:

gdm[8707]: Handling message: 'START_NEXT_LOCAL'
gdm[8723]: gdm_slave_greeter: Running greeter on :0
gdm[8723]: gdm_slave_greeter: Greeter on pid 8737
gdm[8723]: Sending GREETPID == 8737 for slave 8723
gdm[8707]: Handling message: 'GREETPID 8723 8737'
gdm[8707]: Got GREETPID == 8737
gdm[8707]: gdm_socket_handler: Accepting new connection fd 8
gdm[8707]: Handling user message: 'VERSION'
gdm[8707]: Handling user message: 'GET_CONFIG gui/GtkRC=/usr/share/themes/Default/gtk-2.0/gtkrc'
gdm[8707]: Handling user message: 'GET_CONFIG gui/GtkTheme=Default'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/XineramaScreen=0'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/GraphicalThemedColor=#76848F'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/ShowLastSession=true'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/ShowGnomeFailsafeSession=true'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/ShowXtermFailsafeSession=true'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/SessionDesktopDir=/etc/X11/sessions/:/etc/dm/Sessions/:/usr/share/gdm/BuiltInSessions/:/usr/share/xsessions/'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/DefaultSession=gnome.desktop'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/TimedLoginDelay=30'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/HaltCommand=/usr/bin/poweroff;/sbin/poweroff;/sbin/shutdown -h now;/usr/sbin/shutdown -h now'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/RebootCommand=/usr/bin/reboot;/sbin/reboot;/sbin/shutdown -r now;/usr/sbin/shutdown -r now'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/SuspendCommand='
gdm[8707]: Handling user message: 'GET_CONFIG daemon/Configurator=/usr/sbin/gdmsetup --disable-sound --disable-crash-dialog'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/GraphicalThemeRand=false'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/GraphicalTheme=circles'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/GraphicalThemeDir=/usr/share/gdm/themes/'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/SystemMenu=true'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/ConfigAvailable=true'
gdm[8707]: Handling user message: 'CLOSE'
gdm[8707]: gdm_socket_handler: Accepting new connection fd 8
gdm[8707]: Handling user message: 'VERSION'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/ChooserButton=true'
gdm[8707]: Handling user message: 'GET_CONFIG daemon/TimedLoginEnable=false'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/Use24Clock=false'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/UseInvisibleInEntry=false'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/UseCirclesInEntry=false'
gdm[8707]: Handling user message: 'GET_CONFIG gui/MaxIconHeight=128'
gdm[8707]: Handling user message: 'GET_CONFIG gui/MaxIconWidth=128'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/DefaultFace=/usr/share/pixmaps/nobody.png'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/Include='
gdm[8707]: Handling user message: 'GET_CONFIG greeter/Exclude=bin,daemon,adm,lp,sync,shutdown,halt,mail,news,uucp,operator,nobody,gdm,postgres,pvm,rpm,nfsnobody,pcap'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/IncludeAll=false'
gdm[8707]: Handling user message: 'GET_CONFIG security/AllowRoot=true'
gdm[8707]: Handling user message: 'GET_CONFIG security/AllowRemoteRoot=true'
gdm[8707]: Handling user message: 'GET_CONFIG greeter/MinimalUID=100'
gdm[8707]: mainloop_sig_callback: Got signal 17

(In reply to comment #4)
> Does commenting out the MinimalUid configuration value in gdm.conf make a
> difference?
> 

No, no difference


Thanks for looking on that

The crash on my box happens when using IncludeAll=true (which is used by default on Ubuntu) and a theme with a faces list (I changed a setting to try the bug and it was the switch from the default theme to one with a faces list). I'll ping the submitter to know if the has the same options change

I don't see this problem in CVS head using the greeter with the happygnome-list theme.  Do you see the problem with happygnome-list? Perhaps it is specific to the Ubuntu theme?  If so, could you attach the theme you are using?

I get the crash using the CVS from yesterday with no patch (out of the gdm.conf changes) and using happygnome-list. Maybe it's due to some face (but I've no ~/.face set atm).
Is there a way to get a backtrace of the crash/start the slave with gdb?

FYI I am having this problem on gentoo as well. Using GDM 2.13.0.4

The crash happens when I try to configure gdm from the login screen. Running gdmsetup from a terminal while logged on doesn't crash.

Any ideas ?

Sebastien, 

Thanks for helping me look into this.  And thanks for verifying that the problem happens even when using gdm from CVS head and using happygnome-list.  Do you also see the problem using gdmlogin with the face browser instead of gdmgreeter?

There unfortunately is not real easy way to debug the slaves.  If they crash due to a core, they typically will leave a core file on the system, often in the root directory (/) or in /var/lib/gdm or /var/gdm.  Look there.  However, the GDM slave can "crash" for reasons that do not generate a core file.  The GDM slaves can choose to exit without starting based on things like what signals the slave receives from the Xserver, etc.

I have tested changing my gdm.conf so that MinimalUID is uncommented, I am using gdmgreeter, and using happygnome-list, and I don't see any crashing problems.

The best way to track down the problem is to add syslog() calls and print out stuff in the slave code to track down exactly where the crash is happening.
Note that the stuff for setting up the users is called from greeter_item_ulist.c 
where the code calls gdm_users_init.  It would be useful to put a syslog() call right after that call and see if the slave is crashing in the gdm_users_init () function or after setting up the users.  Then based on what you see, keep tracking down the problem via adding such syslog() calls.  Yes, it is a pain, but that's the best way I have found for tracking down problems like this.

Unless you are lucky.  You might have luck setting DOING_GDM_DEVELOPMENT=1 and then running gdmgreeter from a terminal.  If you see the problem happen when running this way, then you can use a debugger to trace the code and see what's going on.  However, setting DOING_GDM_DEVELOPMENT turns off a lot of features and many problems you see using GDM for real don't show up when running this way.

I'm a little confused about Islam's comments.  This seems like perhaps a different bug.  gdmsetup was generating some assert warnings that I think were causing it to crash sometimes.  I just fixed this in CVS head, so perhaps the problem with gdmsetup core dumping is fixed now.  

My understanding is that the problem Sebastien Bacher is reporting is that
gdmgreeter crashes when you turn on IncludeAll and use a greeter theme that has the userlist (face browser) turned on.  Islam's issue seems to be that gdmsetup crashes when you try to start gdmsetup from the login screen.  Is this right?

It happens with gdmlogin too and "DOING_GDM_DEVELOPMENT=1 /usr/lib/gdm/gdmgreeter" doesn't crash. You understanding of the issue I describe is right, I'll try to debug it with the syslog() method

Yes, what you say is true. I updated my gdm to the one in cvs, and gdm stopped crashing when I tried to configure it from the login screen.

However when I tried to select a theme with the face browser, it kept crashing/respawning , till the startup script broke in, or I did gdm-stop.

Also I noticed that switching between greeter login and themed login is not possible, without restaring the X server, but maybe this is a different issue.
Sorry for meddling things. Thanks.

I've tracked the crash to daemon/gdmconfig.c: 

"static gboolean
path_is_local (const char *path)"

with gdb:

2233                    if (g_stat (path, &statbuf) == 0) {
(gdb)
2234                      char *type = filesystem_type ((char *)path, (char *)path, &statbuf);
(gdb) p path
$4 = 0x808db78 "/home"
(gdb) n
2235    gboolean is_local = ((strcmp (ve_sure_string (type), "nfs") != 0) &&
(gdb) p path
$5 = 0x2 <Address 0x2 out of bounds>
(gdb) n
2236                                                 (strcmp (ve_sure_string (type), "afs") != 0) &&
(gdb)
2237                                                 (strcmp (ve_sure_string (type), "autofs") != 0) &&
(gdb)
2238                                                 (strcmp (ve_sure_string (type), "unknown") != 0) &&
(gdb)
2239                                                 (strcmp (ve_sure_string (type), "ncpfs") != 0));
(gdb)
2241     g_hash_table_insert (fstype_hash, g_strdup (path), local);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0xb78437b8 in IA__g_strdup (str=0x2 <Address 0x2 out of bounds>) at gstrfuncs.c:90
90            length = strlen (str) + 1;


config.h lists "#define FSTYPE_MNTENT"

Hmm.  This is really weird.  It looks like the call to filesystem_type (in daemon/fstype.c) is corrupting the value of the path variable.  The only change to the fstype.c file was changing the code to use functions like g_chmod instead of chmod, etc.  This shouldn't cause any problems like this, I would think.
You might try backing out the patch on 12/22/2005 to see if this fixes the problem.  Or it would probably be easier to use the debugger and step into the filesystem_type function and see exactly where it is corrupting memory.  Can you do this since I'm not seeing the problem in my setup.

Thanks.

> (gdb)
> 2234                      char *type = filesystem_type ((char *)path, (char *)path, &statbuf);
> (gdb) p path
> $4 = 0x808db78 "/home"
> (gdb) n
> 2235    gboolean is_local = ((strcmp (ve_sure_string (type), "nfs") != 0) &&
> (gdb) p path
> $5 = 0x2 <Address 0x2 out of bounds>

filesystem_type might be modifying and/or freeing path.  Given the casts the function probably takes non-const char* parameters, which is a good indicator that it might take ownership of what gets passed in.

(from inside filesystem_type_uncached):

> if (S_ISLNK (statp->st_mode))
>   p = dirname (relpath);
>  else
>   p = relpath;

dirname() inserts a NUL character inside the string that gets passed into it, rather than returning new memory.  g_path_get_dirname() might be better.

>   if (p != relpath)
>     free (p);
This isn't a good check if you don't use g_path_get_dirname(). dirname() might return "." or statically allocated memory.  It won't ever return memory the user should free.   If you switch to g_path_get_dirname() you should probably switch the above free to g_free ().

Could someone test Ray's suggestions and see if they fix the problem?  If so, I'll accept a patch to fix this.

Nothing change the variable from the function but changed during the return. 

I've noticed that during the build:

" fstype.c: In function 'filesystem_type_uncached':
fstype.c:298: warning: implicit declaration of function 'g_stat'"

An "#include <glib/gstdio.h>" fixes the crash

Created attachment 57614 [details] [review]
fixes the issue

Fixed in CVS head.  Could you test?

The bug is still here, you moved both glib defines to an #ifdef case not used when building on Ubuntu, reopening

*sigh*.  I think I got this right now.  Just fixed again in CVS head.  Can you
test and verify before I do another release?

current CVS works fine, thank you

Thanks, Sebastien for working this through with me, and apologies for creating the extra hassle.  I'll do another release of GDM sometime next week so people have access to a current non-coredumping version of GDM.