GNOME Bugzilla – Bug 345118
gdmsetup is either TOO slow or unconfigurable
Last modified: 2006-07-17 19:07:39 UTC
I run Fedora Core 5. When I try to configure the login screen using gdmsetup the window (only that one) locks up. All the icons, toolbars, etc. are displayed but I am unable to use them. I cannot close the window and I have to kill it. The System Monitor shows that the processor usage when gdmsetup runs is 100%. I can't understand what gdmsetup does which takes 100% of a 2.2 GHz processor. I don't know if that is very slow but I don't think so. I updated to gdm 2.15.5 with the hope that something has changed but same luck. I am forced to change /usr/share/gdm/defaults.conf by hand.
*** Bug 345119 has been marked as a duplicate of this bug. ***
Can you run trace on the process (or run in a debugger) and see what it is doing while it is hanging? Note, if you are loading users over NIS and have "All Users" turned on, then the delay is expected. The documentation explains to not use this configuration with NIS. Brian
I tried to do as you said Brian. # ltrace gdmsetup 2>gdmsetup-trace The following is being repeated all the time: read(4, "G", 1) = 1 read(4, "D", 1) = 1 read(4, "M", 1) = 1 read(4, " ", 1) = 1 g_string_insert_c(0x9bdafb0, -1, 32, 16384, 0x9cc6924) = 0x9bdafb0 read(4, "2", 1) = 1 read(4, ".", 1) = 1 read(4, "1", 1) = 1 read(4, "5", 1) = 1 g_string_insert_c(0x9bdafb0, -1, 53, 16384, 0x9cc6924) = 0x9bdafb0 read(4, ".", 1) = 1 read(4, "5", 1) = 1 read(4, "\n", 1) = 1 g_string_free(0x9bdafb0, 0, 1, 16384, 0x9cc6924) = 0x9cc54d0 sscanf(0x9cc54d4, 0x8068f5c, 0xbff89d74, 0xbff89d70, 0xbff89d6c) = 3 sscanf(0x8068fd4, 0x8068f5c, 0xbff89d64, 0xbff89d60, 0xbff89d5c) = 4 g_free(0x9cc54d0, 0x8068f5c, 0xbff89d64, 0xbff89d60, 0xbff89d5c) = 0x9cc54b0 g_strdup_printf(0x806952d, 0x9cc6858, 0x49268ac0, 0x4e1b31e0, 0x9cc54d0) = 0x9cc67a8 strlen("GET_CONFIG greeter/Logo :0.0\n") = 29 send(4, 0x9cc67a8, 29, 16384, 0x9cc54d0) = 29 g_free(0x9cc67a8, 0x9cc67a8, 29, 16384, 0x9cc54d0) = 0x9cc66f0 g_string_new(0, 0x9cc67a8, 29, 16384, 0x9cc54d0) = 0x9c21360 read(4, "O", 1) = 1 read(4, "K", 1) = 1 read(4, " ", 1) = 1 read(4, "\n", 1) = 1 g_string_free(0x9c21360, 0, 1, 16384, 0x9cc54d0) = 0x9cc6848 g_strdup_printf(0x806952d, 0x8068f1a, 1, 16384, 0x9cc54d0) = 0x9cc68e8 strlen("CLOSE\n") = 6 send(4, 0x9cc68e8, 6, 16384, 0x9cc54d0) = 6 g_free(0x9cc68e8, 0x9cc68e8, 6, 16384, 0x9cc54d0) = 0x9cc68f0 __errno_location() = 0xb7f6468c close(4) = 0 g_free(0x9cc6858, 0, 0x8068fd4, 5, 0x9cc68b0) = 0x9cc67a0 g_free(0x9cc68b0, 0, 0x8068fd4, 5, 0x9cc68b0) = 0 g_strdup(0x9cc684b, 0x806749d, 0xbff89e68, 0x4e1c0dff, 0x9a747b8) = 0x9cc68e8 g_free(0x9cc6848, 0x806749d, 0xbff89e68, 0x4e1c0dff, 0x9a747b8) = 0x9cc68f0 g_hash_table_replace(0x98e3380, 0x8066b58, 0x9cc68e8, 0x4e1c0dff, 0x9a747b8 <unfinished ...> g_str_hash(0x8066b58, 0x8068fe0, 0xbff89e38, 0x4e149cb1, 0x9cc6848) = 0xa59a612e g_str_equal(0x8066b58, 0x8066b58, 0xbff89e38, 0x4e149cb1, 0x9cc6848) = 1 <... g_hash_table_replace resumed> ) = 0x9a8c230 gtk_notebook_get_type(0, 0x806749d, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x990a760 g_type_check_instance_cast(0x995b018, 0x990a760, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x995b018 gtk_notebook_get_current_page(0x995b018, 0x990a760, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0 gtk_check_button_get_type(0x995b018, 0x990a760, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x9904858 glade_xml_get_widget(0x98ff190, 0x80672ce, 0x1066b58, 0x9cc68e8, 0x9cc5280 <unfinished ...> g_str_hash(0x80672ce, 0x8066b58, 0xbff89e38, 0x4ea2c278, 0x9904858) = 0x48cdafdb g_str_equal(0x9921370, 0x80672ce, 0xbff89e38, 0x4ea2c278, 0x9904858) = 1 <... glade_xml_get_widget resumed> ) = 0x9a1ee00 strcmp("", "/usr/share/pixmaps/gdm-foot-logo"...) = -1 g_signal_handlers_disconnect_matched(0x99a7248, 24, 0, 0, 0) = 1 g_type_check_instance_cast(0x99a7248, 0x9905458, 0, 0, 0) = 0x99a7248 gtk_file_chooser_set_filename(0x99a7248, 0x9cc5280, 0, 0, 0 <unfinished ...> g_str_hash(0x9cc54d0, 19, 0x119d723, 0x4e71bf4c, 0x99ad2d0) = 0xacce08fc g_str_equal(0x9a124b0, 0x9cc54d0, 0x119d723, 0x4e71bf4c, 0x99ad2d0) = 1 <... gtk_file_chooser_set_filename resumed> ) = 1 g_type_check_instance_cast(0x99a7248, 80, 0, 0, 0) = 0x99a7248 g_signal_connect_data(0x99a7248, 0x8067960, 0x80542c0, 0x99a7248, 0) = 15198 gtk_toggle_button_get_type(0x99a7248, 0x8067960, 0x80542c0, 0x99a7248, 0) = 0x99047a8 g_type_check_instance_cast(0x9a1ee00, 0x99047a8, 0x80542c0, 0x99a7248, 0) = 0x9a1ee00 g_free(0x9cc5280, 0x99a7248, 0x9bde2c0, 0x4e1f666c, 0x4e1cc7d0) = 0x9cc5518 g_str_hash(0x4e61c263, 0x40000001, 140, 0x4e71bf4c, 0x99c2820) = 0x7d2c88cb g_str_equal(0x9952118, 0x4e61c263, 140, 0x4e71bf4c, 0x99c2820) = 0 g_str_equal(0x99522c8, 0x4e61c263, 140, 0x4e71bf4c, 0x99c2820) = 0 g_str_equal(0x99e4570, 0x4e61c263, 140, 0x4e71bf4c, 0x99c2820) = 1 gtk_file_chooser_get_type(0xbff8a11c, -1, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x9905458 g_type_check_instance_cast(0x99a70e8, 0x9905458, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x99a70e8 gtk_file_chooser_get_filename(0x99a70e8, 0x9905458, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x9cc5280 g_type_check_instance_cast(0x99a70e8, 80, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x99a70e8 g_object_get_data(0x99a70e8, 0x806749d, 0xbff89ea8, 0x4e1e1a0c, 0xbff8a11c) = 0x8066b58 g_strdup(0x8066b58, 0x806749d, 0x99056b0, 0x4e1dc5c1, 1) = 0x9cc6960 g_strchug(0x9cc6960, 0x806749d, 0x99056b0, 0x4e1dc5c1, 1) = 0x9cc6960 g_strchomp(0x9cc6960, 0x806749d, 0x99056b0, 0x4e1dc5c1, 1) = 0x9cc6960 strchr("greeter/Logo=/usr/share/pixmaps/"..., '=') = "=/usr/share/pixmaps/gdm-foot-log"... g_hash_table_lookup(0x98e3380, 0x9cc6960, 0x99056b0, 0x4e1dc5c1, 1 <unfinished ...> g_str_hash(0x9cc6960, 0x9cc6960, 50, 0x98e3380, 0x9cc6960) = 0xfc6b46c4 g_str_equal(0x9a74278, 0x9cc6960, 50, 0x98e3380, 0x9cc6960) = 1 <... g_hash_table_lookup resumed> ) = 0x9a747b8 g_free(0x9cc6960, 0x9cc6960, 0x99056b0, 0x4e1dc5c1, 1) = 0 g_strdup(0x8066b58, 0x9cc6960, 0xbff89e38, 0x8061121, 0x9cc6960) = 0x9cc6960 g_strchug(0x9cc6960, 0x9cc6960, 0xbff89e38, 0x8061121, 0x9cc6960) = 0x9cc6960 g_strchomp(0x9cc6960, 0x9cc6960, 0xbff89e38, 0x8061121, 0x9cc6960) = 0x9cc6960 strchr("greeter/Logo=/usr/share/pixmaps/"..., '=') = "=/usr/share/pixmaps/gdm-foot-log"... g_getenv(0x8068e98, 61, 0xbff89e38, 0x8061121, 0x9cc6960) = 0xbff8cf67 g_strdup(0xbff8cf67, 61, 0xbff89e38, 0x8061121, 0x9cc6960) = 0x9cc6848 g_strdup_printf(0x8068fef, 0x9cc6960, 0x9cc6848, 0x8061121, 0x9cc6960) = 0x9cc6908 socket(1, 1, 0) = 4 connect(4, 0xbff89d7a, 110, 0x4e42a4b2, 16) = 0 g_strdup_printf(0x806952d, 0x8068f38, 0x9cc69b8, 0x9cc69b8, 0x9cc69d4) = 0x9cc68f8 strlen("VERSION\n") = 8 send(4, 0x9cc68f8, 8, 16384, 0x9cc69d4) = 8 g_free(0x9cc68f8, 0x9cc68f8, 8, 16384, 0x9cc69d4) = 0x9cc6990 g_string_new(0, 0x9cc68f8, 8, 16384, 0x9cc69d4) = 0x9c21360 read(4, "G", 1) = 1 read(4, "D", 1) = 1 read(4, "M", 1) = 1 read(4, " ", 1) . . . . . Hope that helps.
The stack trace does help narrow down things, but doesn't highlight the specific problem. Note that gdmsetup has handler functions (logo_toggle_timeout, logo_filechooser_response, hookup_plain_logo, hookup_remote_plain_logo). I'm guessing that something weird might be happening, like the logo_filechooser_response function is getting called over and over again even though you aren't actually changing the value. Does changing the value of the Logo or ChooserButtonLogo keys in the GDM configuration make it behave better? Perhaps there is some bad error handling code that causes gdmsetup to get stuck in a loop if it is pointing to an invalid file on your system and tries to reset it to a different value that is also invalid or something? It would be useful if you could add some gdm_common_debug calls to the above functions and print out information about what the function is doing. Perhaps this could help us track down the problem. Note that the gdm_common_debug calls cause messages to appear in stderr for gdmsetup so you should run it from the command line to see the messages appear in the window. If you call gdm_common_openlog() it will send the messages to syslog.
I think I have found the problem. I tried to build gdm from source and it worked! It worked because the folders /root/gdm/share/sounds and /root/gdm/share/pixmaps were not present (/root/gdm/ is my prefix). Note that gdmsetup complained three times for not founding the sounds folder and one for not founding the pixmaps one. I created the pixmaps folder and put an item. It still worked. But when I created the sounds folder it stacked again. I forgot, sorry about the dup bug!
+ Trace 68941
A more useful debugging trace.
I'm a bit confused by your report. You say you upgraded to GDM 2.15.5 and still had the same problem. Then you said you rebuild from source and it worked. How did you upgrade to GDM 2.15.5 without building from source? I also find it suspicious that GDM is failing when certain directories are present. Especially since the directories you mention (share/sounds) is not present. gdmsetup is hardcoded to set the file_chooser for soundfiles to DATADIR/sounds. It looks like it is failing when gdmsetup is calling gtk_file_chooser_set_filename in the logo_filechooser_response function. It would be useful if you added printf statements to this function to find out what it is trying to set the filename value. The code makes an effort to protect the value from ever being set to NULL. Perhaps it is failing because we are setting the value to a filename that does not exist or something, though it seems bad if the GTK file_chooser code would cause a crash just because the filename is incorrect. Does upgrading to the latest GTK code help? Perhaps this is a bug in the file_chooser GTK logic? If it is failing because we are setting the filename to a bad value, does hardcoding a good value (a real file that has read permissions) make gdmsetup not crash?
Thinking about this problem more, I do not think this is really a GDM bug. I suspect what is happening is that the file chooser dialog is doing something like looking at all the files in the directories used for pixmaps and icons, perhaps so it can figure out what icon is to be used for each file. If the file chooser dialog hangs while initializing, then this is probably a performance issue with the file chooser dialog.
So I think this may have broke when gtk merged its async filechooser branch. So gdmsetup has some code in the logo_filechooser_response handler that does: <disconnect logo_filechooser_response from "selection-changed" signal> gtk_file_chooser_set_filename (..., filename) <reconnect logo_filechooser_response to "selection-changed" signal> In gtk 2.10 I think set_filename is an asynchronous call that won't be completed until after going back to the main loop. This means the disconnect/reconnect trick isn't sufficient to prevent recursion
Created attachment 68947 [details] [review] don't call set_filename if the filename is already set Does the above patch fix things up?
I built attachment 68947 [details] [review] into rawhide and the problem has been confirmed fixed on a downstream report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193214#c12
Thanks, fixed in CVS head and 2.14 branch.