GNOME Bugzilla – Bug 345609
ClockApplet dies when trying to open the calendar
Last modified: 2007-08-23 20:22:26 UTC
Distribution: Debian testing/unstable Package: gnome-panel Severity: normal Version: GNOME2.14.2 unspecified Gnome-Distributor: Debian Synopsis: ClockApplet dies when trying to open the calendar Bugzilla-Product: gnome-panel Bugzilla-Component: clock applet Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.14.1) Description: Description of the crash: ClockApplet crashes when I try to open a calendar app to enter some appointments. Steps to reproduce the crash: 1. Click on the clock applet, the calendar window appears showing the current month 2. Double click on a day. The calendar window "empties" (it turns white) 3. Click on the white calendar window. Crash. Expected Results: Some calendar application would show up and allow me to enter appointments, etc. How often does this happen? Every time. Additional Information: I don't have Evolution installed, so maybe the applet is expecting to be able to open Evolution and let it handle the task. I don't know really if there is any calendar application in Gnome besides Evolution. Debugging Information: Backtrace was generated from '/usr/libexec/ClockApplet' (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 -1497037120 (LWP 31504)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 68987
Thread 1 (Thread -1497037120 (LWP 31504))
------- Bug created by bug-buddy at 2006-06-21 22:34 -------
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
I tried; however I'm not sure how successful this was. I installed the debug packages for glib, gtk+ and gnomeui, but the stack trace still shows "no debug symbols" at some points. Can you tell me which other packages should I try to add debug symbols to? This is the backtrace I currently get. I note that there's a call to gtk_calendar_set_display_options with calendar=NULL, which is probably the cause of the crash. I don't know what package is the one in the #5 and #6 frames though -- I think it must be gnome-panel, because I couldn't find a "-dbg" package for it. Should I compile it from CVS? Backtrace was generated from '/usr/libexec/ClockApplet' (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 -1497016640 (LWP 5847)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 69047
Thread 1 (Thread -1497016640 (LWP 5847))
I found instructions for building an unstripped Debian package. In the process, the 2.14.1 panel got upgraded to 2.14.2, but it still crashes. The backtrace I get is this: Backtrace was generated from '/usr/libexec/ClockApplet' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1496295744 (LWP 3619)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 69048
Thread 1 (Thread -1496295744 (LWP 3619))
Additional info -- attached to the process with GDB and got to the offending frame. Displaying the "cd" argument shows the calendar being NULL. The code in applets/clock/clock.c, lines 1430-1437 appears to be the culprit -- it never checks whether the pointer returned by gtk_calendar_new() is NULL. The interesting thing would be, however, knowing _why_ gtk_calendar_new() is returning NULL ... (gdb) frame 5
+ Trace 69050
$2 = {applet = 0x80bf800, clockw = 0x80d8818, toggle = 0x80db008, props = 0x0, about = 0x0, calendar_popup = 0x0, calendar = 0x0, task_list = 0x0, appointment_list = 0x0, appointments_model = 0x8118f10, tasks_model = 0x8118dd0, tasks_filter = 0x80914c0, client = 0x8154ba8, format = CLOCK_FORMAT_24, custom_format = 0x80a9ed8 "", showseconds = 0, showdate = 1, gmt_time = 0, showweek = 1, config_tool = 0x80a9758 "time-admin", current_time = 1151253516, timeformat = 0x81233b0 "%a %e de %b, %H:%M", timeout = 16, orient = 1, size = 24, fixed_width = 136, fixed_height = 17, showseconds_check = 0x0, showdate_check = 0x0, gmt_time_check = 0x0, custom_hbox = 0x0, custom_label = 0x0, custom_entry = 0x0, custom_format_shown = 0, can_handle_format_12 = 0, listeners = { 654311428, 671088645, 687865862, 704643079, 721420296, 738197513, 754974730}} (gdb) list 1430,1437 1430 cd->calendar = gtk_calendar_new (); 1431 g_object_add_weak_pointer (G_OBJECT (cd->calendar), 1432 (gpointer *) &cd->calendar); 1433 1434 options = gtk_calendar_get_display_options (GTK_CALENDAR (cd->calendar)); 1435 if (cd->showweek) 1436 options |= GTK_CALENDAR_SHOW_WEEK_NUMBERS; 1437 gtk_calendar_set_display_options (GTK_CALENDAR (cd->calendar), options);
A trivial patch from someone totally unfamiliar with Gtk/Gnome development. At least with this patch, the clock doesn't crash. However, after the bug is triggered, the calendar will no longer be shown, and instead it'll show an annoying dialog box. There doesn't seem to be a way for gtk_calendar_new() to return to a sane state.
Created attachment 68055 [details] [review] Trivial patch so the clock doesn't crash.
http://bugzilla.gnome.org/show_bug.cgi?id=340622 looks related to me, I can't reproduce the problem after applying the patch in that bugreport.
*** Bug 340815 has been marked as a duplicate of this bug. ***
*** Bug 349536 has been marked as a duplicate of this bug. ***
*** Bug 351570 has been marked as a duplicate of this bug. ***
*** Bug 352963 has been marked as a duplicate of this bug. ***
*** Bug 356823 has been marked as a duplicate of this bug. ***
*** Bug 357455 has been marked as a duplicate of this bug. ***
*** Bug 360494 has been marked as a duplicate of this bug. ***
Patch is not okay: gtk_calendar_new() should not fail and really, there's no reason for it to fail, so that's what we'd need to investigate. Looking at all the bug reports, they're all from Debian/Ubuntu and from GNOME 2.14.x. Can someone still reproduce? This might have been caused by some Debian patch in GTK+ or gnome-panel making things crash in the 2.14.x version... Marking as NEEDINFO and waiting for a 2.16 (or more recent) crash. I'm also interested in knowing if it's still crashing now in Debian with 2.14.
Did I mention that Evolution is supposed not to be installed? I don't have 2.16 handy, so I can't test that. I'm currently using gnome-panel 2.14.3-4 (which is stock Debian Etch AFAICT) and it doesn't crash anymore, but once the calendar pops up it never goes away if I double-click on a day. One interesting thing to note is that as soon as I force a redraw of the calendar widget, it stays blank, so I assume the involved process is stuck. (Since it's a "keep on top" window, it's hard to do this by normal means, so what I did was to change to another VT and then back to this X session). More info: attaching with GDB to the process before it dies, and then redoing the crash actions leads to this stack trace: Program received signal SIGABRT, Aborted. 0x00002aee2285f07b in raise () from /lib/libc.so.6 (gdb) bt
+ Trace 102255
*** Bug 344058 has been marked as a duplicate of this bug. ***
I've still not seen a crash report for this bug in 2.16/2.18.
Closing since there's no recent report of this crash. If you can still reproduce with 2.16/2.18, please reopen.
Created attachment 90023 [details] screenshot of stuck ClockApplet in 2.14
Oh good! So nobody knows whether it was fixed or not, but the developers were too busy to try the test case for themselves. Way to go! Since you have the sources you could verify whether the code still stands as it was -- it was clearly buggy when I looked at it. I don't understand the attitude of dropping the bug in the floor without taking any action about it. I am attaching a screenshot of the applet stuck as I described in comment #16. This is still 2.14 (Debian Lenny package).
I went to check the code in http://svn.gnome.org/viewcvs/gnome-panel/trunk/applets/clock/clock.c?revision=10459&view=markup and I see that in create_calendar() there is no check at all about the return value from calendar_window_new being NULL. So it very much looks like the bug has not been fixed, but I don't have any experience with the Gnome code or GTK+ programming. On the other hand I don't see calendar_window_init being called anywhere in any case, so there's probably code being executed somewhere I am not seeing.
First, it'd be great if you could use two minutes to take a look at http://live.gnome.org/CodeOfConduct (In reply to comment #21) > Oh good! So nobody knows whether it was fixed or not, but the developers were > too busy to try the test case for themselves. Way to go! I'm sorry, but it seems you don't realize how busy we are and how much of our free time we're giving only to triage bugs (I'm not talking about fixing bugs, but really about triaging). You also appear to think that I'm closing the bug without having tried to reproduce it in more recent versions of GNOME, which is wrong since I tried. > Since you have the sources you could verify whether the code still stands as it > was -- it was clearly buggy when I looked at it. Did you read comment #15 about the patch you proposed? There is no obvious error here in the code. > I don't understand the attitude of dropping the bug in the floor without taking > any action about it. Everything is telling me the bug only appears in 2.14 which is not maintained anymore. I've tried to reproduce the bug, I've asked if it still happens in 2.16 or 2.18 and nobody replied to this. What else should I do?
(In reply to comment #22) > I went to check the code in > http://svn.gnome.org/viewcvs/gnome-panel/trunk/applets/clock/clock.c?revision=10459&view=markup > and I see that in create_calendar() there is no check at all about the return > value from calendar_window_new being NULL. So it very much looks like the bug > has not been fixed, but I don't have any experience with the Gnome code or GTK+ > programming. calendar_window_new() does never return NULL. > On the other hand I don't see calendar_window_init being called anywhere in any > case, so there's probably code being executed somewhere I am not seeing. Yes, calendar_window_init() is being called during the object creation (ie, in g_object_new()).
*** Bug 467607 has been marked as a duplicate of this bug. ***