GNOME Bugzilla – Bug 366996
crash in Time and Date: Right-clicked the clock ...
Last modified: 2006-11-17 00:03:10 UTC
Version: 2.15.5 What were you doing when the application crashed? Right-clicked the clock applet and selected "Adjust Date & Time". Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 32481280 vsize: 0 resident: 32481280 share: 0 rss: 10838016 rss_rlim: 0 CPU usage: start_time: 1162140194 rtime: 0 utime: 13 stime: 0 cutime:11 cstime: 0 timeout: 2 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/time-admin' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1225766640 (LWP 6519)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 79866
Thread 1 (Thread -1225766640 (LWP 6519))
Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 18935808 vsize: 0 resident: 18935808 share: 0 rss: 7380992 rss_rlim: 0 CPU usage: start_time: 1162140981 rtime: 0 utime: 7 stime: 0 cutime:7 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/time-admin' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1226004288 (LWP 30269)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 79874
Thread 1 (Thread -1226004288 (LWP 30269))
Confirming, nice trace, unique. Thanks, Albert! Note: Carlos, please note that the original stacktrace looks like the dreaded general "crash on starting" bug. Possibly some of those duplicates with low info actually may be this issue, too.
I got a better stack trace for Thread 1 by installing the libgnomeui-0-dbg package in Ubuntu. -- Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 18931712 vsize: 0 resident: 18931712 share: 0 rss: 7372800 rss_rlim: 0 CPU usage: start_time: 1162142312 rtime: 0 utime: 7 stime: 0 cutime:7 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/time-admin' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1225271104 (LWP 15623)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 79896
Thread 1 (Thread -1225271104 (LWP 15623))
nice stacktrace, good to see this - seems like some of the bugs marked as duplicates of bug 351603 might be duplicates of this one here - even more important to fix this issue here.
Seems to me 100% a installation issue... it isn't finding a .glade file in the path it's told. Could you check in your "dpkg -L gnome-system-tools" output which .glade files are being installed and that they exist in your filesystem? also pasting here the stderr output of the tool would be helpful, it should tell you where is it searching for the file.
~$ dpkg -L gnome-system-tools|fgrep glade /usr/share/gnome-system-tools/interfaces/boot.glade /usr/share/gnome-system-tools/interfaces/common.glade /usr/share/gnome-system-tools/interfaces/disks.glade /usr/share/gnome-system-tools/interfaces/network.glade /usr/share/gnome-system-tools/interfaces/services.glade /usr/share/gnome-system-tools/interfaces/shares.glade /usr/share/gnome-system-tools/interfaces/time.glade /usr/share/gnome-system-tools/interfaces/users.glade ~$ /usr/bin/time-admin (time-admin:10287): libglade-WARNING **: could not find glade file '/usr/local/share/gnome-system-tools/interfaces/common.glade' ** ERROR **: Could not load /usr/local/share/gnome-system-tools/interfaces/common.glade
If I symlink /usr/share/gnome-system-tools to /usr/local/share/gnome-system-tools, I no longer get the error messages on stderr, but time-admin fails within a different function. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 32477184 vsize: 0 resident: 32477184 share: 0 rss: 10838016 rss_rlim: 0 CPU usage: start_time: 1162258542 rtime: 0 utime: 14 stime: 0 cutime:14 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/time-admin' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1225856832 (LWP 10464)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 80761
Thread 1 (Thread -1225856832 (LWP 10464))
When I step through the code, g_new0() returns NULL at tz-map.c:64 but the code never tests for that condition. tzmap = g_new0 (ETzMap, 1); The description of g_new0 says, "If any call to allocate memory fails, the application is terminated. This also means that there is no need to check if the call succeeded." http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html However, the application does not terminate at line 64 where g_new0 fails. It instead crashes further down at line 82. Another strange thing is that line 65 does not cause a segfault, which I would expect since it is dereferencing the NULL pointer. tzmap->tool = GST_TOOL (tool); I can't get gdb to step into g_new0(), even though I have the libglib2.0-dev Ubuntu package installed. Nevertheless, the stack shows IA__g_malloc0(n_bytes=24) at gmem.c:144 Finally, if I patch tz-map.c to report an error when tzmap is NULL, that line is never called. What am I missing here? --- tz-map.c.orig 2006-10-30 21:51:42.000000000 -0500 +++ tz-map.c 2006-10-30 21:51:46.000000000 -0500 @@ -62,6 +62,9 @@ int i; tzmap = g_new0 (ETzMap, 1); + if (!tzmap) + g_error ("Unable to allocate timezone map."); + tzmap->tool = GST_TOOL (tool); tzmap->tzdb = tz_load_db (); if (!tzmap->tzdb)
*** Bug 373334 has been marked as a duplicate of this bug. ***
The second issue was fixed in g-s-t 2.15.6, the first one is totally either a packaging error or a mixed package/compiled installation. I'll close as FIXED, thanks!
time-admin 2.16.1 from g-s-t 2.15.6 works correctly for me. Marking as VERIFIED.