After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 502975 - Gdm crashes in g_hash_table_lookup_extended when using custom commands
Gdm crashes in g_hash_table_lookup_extended when using custom commands
Status: RESOLVED OBSOLETE
Product: gdm
Classification: Core
Component: general
2.20.x
Other All
: Normal critical
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-11 05:12 UTC by Philippe Troin
Modified: 2010-06-04 20:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Custom.conf to be used. (3.68 KB, text/plain)
2007-12-11 05:13 UTC, Philippe Troin
  Details
patch to try (1.01 KB, patch)
2008-10-24 06:44 UTC, Brian Cameron
none Details | Review

Description Philippe Troin 2007-12-11 05:12:49 UTC
Steps to reproduce:
1. Use the attach custom.conf
2. Try the custom button ("Hibernate") with a theme that supports custom buttons

Watch it crash.



Stack trace:
Valgrind backtrace:

==23387== Invalid read of size 4
==23387==    at 0x492300C: g_hash_table_lookup_extended (in /lib/libglib-2.0.so.0.1400.4)
==23387==    by 0x808D741: gdm_config_peek_value (gdm-config.c:1246)
==23387==    by 0x808D79F: gdm_config_get_value (gdm-config.c:1272)
==23387==    by 0x805A066: gdm_daemon_config_get_value_string (gdm-daemon-config.c:251)
==23387==    by 0x8050EA9: custom_cmd_restart (gdm.c:781)
==23387==    by 0x8050E04: custom_cmd (gdm.c:757)
==23387==    by 0x8055415: gdm_handle_message (gdm.c:2584)
==23387==    by 0x8080029: gdm_connection_handler (gdm-net.c:182)
==23387==    by 0x495F8AC: (within /lib/libglib-2.0.so.0.1400.4)
==23387==    by 0x493010B: g_main_context_dispatch (in /lib/libglib-2.0.so.0.1400.4)
==23387==    by 0x493354E: (within /lib/libglib-2.0.so.0.1400.4)
==23387==    by 0x49338F8: g_main_loop_run (in /lib/libglib-2.0.so.0.1400.4)
==23387==  Address 0xEE3B4EC is not stack'd, malloc'd or (recently) free'd


Other information:
Comment 1 Philippe Troin 2007-12-11 05:13:28 UTC
Created attachment 100737 [details]
Custom.conf to be used.
Comment 2 Brian Cameron 2008-01-10 21:51:14 UTC
Using your custom config options, I noticed that when I run gdmsetup and try to modify any of the label strings that it caused the GDM daemon to crash.  I wonder if this is the same problem.  I've attached a patch that fixes this problem.  Please let me know if it also fixes your issue.

If it doesn't fix your problem, could you tar up your theme that uses the Hibernate button.  I'm not able to test since you didn't provide such a theme.
Comment 3 tim 2008-10-24 01:57:11 UTC
I reported a Debian bug 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503143
 with the same problem.

1) add a custom command to gdm login that calls hibernate
path: /usr/sbin/pm-hibernate
give it the label Hibernate
2) restart gdm or reboot to make the label change take effect

3) from the login screen, execute the new Hibernate command

gdm stops. 
Messages like this appear on the console 
gdm[3927] Glib-critical: g_hash_table_lookup_extended: assertion 'hash_table != NULL' failed

I am left in a console as root.

 
This happens in at least two of the standard themes.

My gdm version is: 
Package: gdm
Version: 2.20.7-3



This bug can be confirmed now, I think, although I don't think the severity is critcal.

Note that changing the suspend option to /usr/sbin/pm-suspend 
works great.
Comment 4 tim 2008-10-24 02:11:22 UTC
This new insight should be a giveaway to a developer, I hope: 

When I modify the built in suspend command to be /usr/sbin/pm-hibernate
it works perfectly.

Adding /usr/sbin/pm-hibernate to a custom commands gives me the gdm crash that I reported.

So custom commands are handled differently to the built-in suspend command.

Perhaps there could be a power-management category of custom commands?

Comment 5 Brian Cameron 2008-10-24 02:42:07 UTC
I fixed a crashing problem like this in GDM 2.20.4.

Could you share the stack trace?  I suspect that the original issue reported was actually fixed in GDM 2.20.4 and that we are seeing a new problem.  In fact, I believe this is likely related to bug #517526.

To fix that bug we modified daemon/gdm.c so that the function gdm_final_cleanup removes all signal handlers (to avoid possibly receiving another signal as we are shutting down causing it to get stuck in a loop), and then the halt_machine/restart_machine functions call "_exit (EXIT_SUCCESS);" at the end.
I suspect we need a similar call to "_exit" at the end of custom_cmd_restart.

Also, note that gdm_final_cleanup clears out all configuration data, so it is a bug that we are calling gdm_daemon_config_get_value_string after calling gdm_final_cleanup.  We should move this block of code to before the
gdm_final_cleanup call.

        argv = NULL;
        s = gdm_daemon_config_get_value_string (key_string);
        g_free (key_string);
        if (s != NULL) {
                g_shell_parse_argv (s, NULL, &argv, NULL);
        }

If someone wants to test this fix, I'll commit it upstream if you can verify this works.
 
Comment 6 tim 2008-10-24 06:26:40 UTC
Is there any significance about my observation that putting /usr/sbin/pm-hibernate works perfectly when I put it under the pre-existing command "suspend", but doesn't work when I put it under a Custom command?
Comment 7 Brian Cameron 2008-10-24 06:44:37 UTC
Created attachment 121245 [details] [review]
patch to try


Here is a patch to try.  I'd be interested to hear if this works better.

The Suspend command avoids calling the custom_cmd_restart function, which seems to have errors.  I suspect that's the difference.

Note that if you are just suspending, you probably don't want to restart.  Restart means that you basically are telling GDM that the command will cause GDM to exit, like if you are going to shutdown the machine.  You probably want the CustomCommandNoRestart value to be true for this command since I assume you would want GDM to keep running when the suspend is done.  No?
Comment 8 tim 2008-10-24 10:07:00 UTC
I didn't apply your patch, but I think this is a false alarm.
If I activate the setting 
CustomCommandNoRestart0=true

then the command works.


There is a gui interface for this as well in the Edit Command option. 
For me, the bug is closed. 

Comment 9 Brian Cameron 2008-10-24 10:52:45 UTC
Yes, I suspected that would fix your problem.  However, custom commands should also work for commands that actually restart your system (like if you want a command which causes you to reboot directly to another partition or something).  I suspect my patch will address that a bit better, but it would be good if someone could test.

To test this, just define a custom command which does a reboot and make sure GDM behaves okay and doesn't generate any error messages to the syslog.
Comment 10 William Jon McCann 2010-06-04 20:39:05 UTC
Thanks for taking the time to report this bug.
However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.
Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.