GNOME Bugzilla – Bug 378854
gnome-panel crash when running evolution --force-shutdown
Last modified: 2010-02-18 03:55:25 UTC
Steps to reproduce: 1. Wait for evolution to freeze while querying an IMAP server (this happens once in a while, especially with the Scalix evolution plugin) 2. Run evolution --force-shutdown to shutdown evolution 3. bug-buddy window comes up with the stack-trace and states that gnome-panel has crashed but that it does not know the application that crashed in bugzilla so it's up to me to figure out where to file the bug. I hope this is the right place. Stack trace: Memory status: size: 132079616 vsize: 0 resident: 132079616 share: 0 rss: 31641600 rss_rlim: 0 CPU usage: start_time: 1164294374 rtime: 0 utime: 5269 stime: 0 cutime:4739 cstime: 0 timeout: 530 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gnome-panel' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208957264 (LWP 1122)] [New Thread -1211036768 (LWP 9270)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 89037
Thread 1 (Thread -1208957264 (LWP 1122))
Other information: I've installed the gnome-panel-dbg ubuntu package because this had happened several times before, so I hope this stack trace is useful.
Hmm. the code itself doesn't look reassuring either: static void calendar_client_handle_query_completed (CalendarClientSource *source, ECalendarStatus status, ECalView *view) { CalendarClientQuery *query; query = goddamn_this_is_crack (source, view, NULL); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ dprintf ("Query %p completed: %s\n", query, e_cal_get_error_message (status)); if (status != E_CALENDAR_STATUS_OK) { g_warning ("Calendar query failed: %s\n", e_cal_get_error_message (status)); calendar_client_stop_query (source->client, source, query); return; } g_assert (source->query_in_progress != FALSE); g_assert (query == &source->in_progress_query); Anyone got an idea what's going on here?
From what I understand, this would mean we receive the "view-done" signal twice. I don't know if it's possible, but the name makes me think it shouldn't be possible.
Of course, I can't reproduce. Can you still reproduce with 2.18?
Please See : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242824 evolution --force-shutdown, clock-applet crashes in gnome-panel-2.19.3. Distribution: Fedora release 7.89 (Rawhide) Gnome Release: 2.19.3 2007-06-04 (Red Hat, Inc) BugBuddy Version: 2.18.0 System: Linux 2.6.21-1.3175.fc7 #1 SMP Mon May 21 11:35:59 EDT 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: Tango Memory status: size: 75849728 vsize: 75849728 resident: 26472448 share: 22941696 rss: 26472448 rss_rlim: 4294967295 CPU usage: start_time: 1181085996 rtime: 66 utime: 61 stime: 5 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/libexec/clock-applet' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208214832 (LWP 3273)] [New Thread -1229845616 (LWP 3895)] 0x004fe402 in __kernel_vsyscall ()
+ Trace 138629
Thread 1 (Thread -1208214832 (LWP 3273))
*** Bug 444729 has been marked as a duplicate of this bug. ***
We have a good stack trace now.
*** Bug 446401 has been marked as a duplicate of this bug. ***
*** Bug 446249 has been marked as a duplicate of this bug. ***
Confirming bug as there are several duplicates including one from me :)
Ubuntu bug https://bugs.launchpad.net/gnome-panel/+bug/122590 "Binary package hint: gnome-panel It just crashed. ... Binary package hint: gnome-panel It just crashed. ...
+ Trace 144124
I only get the crash after several evolution --force-shutdown (2 is usually enough) if hiding/displaying the calendar between. Sometimes source_data->clients is set to NULL (when the list is empty) while there are still some clients for which backend_died_cb has not yet been called, and then the next time we get into backend_died_cb, it is no longer NULL but contains a small value (I got 0xa, 0x1d) and we get this crash (I also got the applet frozen with a corrupted stacktrace some times, always just after the list is set to NULL).
Hmm I add missed a big detail : source_data changes value, that's why source_data->clients get meaningless
Ok, let's follow a field of the structure at 0x82371e0 (136540640) : calendar_sources_finalize_source_data is called when hiding the calendar : Hardware watchpoint 3: *(136540640 + 12) Old value = 136664096 New value = 0 calendar_sources_finalize_source_data (sources=<value optimized out>, source_data=0x82371e0) at calendar-sources.c:212 212 if (source_data->esource_list) Then this address is used by someone else : Hardware watchpoint 3: *(136540640 + 12) Old value = 0 New value = 2 0xb6f4b59d in pango_layout_set_text (layout=0x82371d0, text=0xbfb2d354 "30", length=-1) at pango-layout.c:951 951 layout->length = strlen (layout->text); But we still point to it : ** (clock-applet:7318): WARNING **: -> The calendar backend for contacts:/// has crashed (client=0x82af420, source_data=0x82371e0, &(source_data->clients) = 0x82371ec, source_data->clients = 0x2). Program received signal SIGSEGV, Segmentation fault. IA__g_slist_remove (list=0x2, data=0x82af420) at gslist.c:207 207 if (tmp->data == data)
And there are actually several different crashes that I face from time to time during my tests, when running evolution --force-shutdown while a backend is being restarted. One where the stack is in CORBA, the other with a destroyed stack. Here is the CORBA one, maybe I should open another bug for it : (clock-applet:18821): libecal-WARNING **: e-cal.c:5089: Unable to contact backend ** (clock-applet:18821): WARNING **: Error preparing the query: '#t': Une exception CORBA s'est produite ** (clock-applet:18821): WARNING **: Error preparing the query: '#t': URI non charg\xe9 ** (clock-applet:18821): WARNING **: Error preparing the query: '#t': URI non charg\xe9 ** (clock-applet:18821): WARNING **: Error preparing the query: '#t': URI non charg\xe9 ==18821== ==18821== Invalid read of size 4 ==18821== at 0x4A8773C: giop_recv_buffer_get (giop-recv-buffer.c:733) ==18821== by 0x4A8BB5D: ORBit_small_invoke_stub (orbit-small.c:658) ==18821== by 0x4A8BD78: ORBit_small_invoke_stub_n (orbit-small.c:575) ==18821== by 0x4A9910B: ORBit_c_stub_invoke (poa.c:2643) ==18821== by 0x42176D5: GNOME_Evolution_Calendar_CalFactory_getCal (Evolution-DataServer-Calendar-stubs.c:426) ==18821== by 0x421BD82: e_cal_new (e-cal.c:1391) ==18821== by 0x8062036: calendar_sources_load_esource_list (calendar-sources.c:325) ==18821== by 0x8062610: backend_restart (calendar-sources.c:420) ==18821== by 0x54BA0B6: g_timeout_dispatch (gmain.c:3488) ==18821== by 0x54B9921: g_main_context_dispatch (gmain.c:2061) ==18821== by 0x54BCD33: g_main_context_iterate (gmain.c:2694) ==18821== by 0x54BD057: g_main_loop_run (gmain.c:2898) ==18821== Address 0x2C is not stack'd, malloc'd or (recently) free'd ==18821== ==18821== Process terminating with default action of signal 11 (SIGSEGV) ==18821== Access not within mapped region at address 0x2C ==18821== at 0x4A8773C: giop_recv_buffer_get (giop-recv-buffer.c:733) ==18821== by 0x4A8BB5D: ORBit_small_invoke_stub (orbit-small.c:658) ==18821== by 0x4A8BD78: ORBit_small_invoke_stub_n (orbit-small.c:575) ==18821== by 0x4A9910B: ORBit_c_stub_invoke (poa.c:2643) ==18821== by 0x42176D5: GNOME_Evolution_Calendar_CalFactory_getCal (Evolution-DataServer-Calendar-stubs.c:426) ==18821== by 0x421BD82: e_cal_new (e-cal.c:1391) ==18821== by 0x8062036: calendar_sources_load_esource_list (calendar-sources.c:325) ==18821== by 0x8062610: backend_restart (calendar-sources.c:420) ==18821== by 0x54BA0B6: g_timeout_dispatch (gmain.c:3488) ==18821== by 0x54B9921: g_main_context_dispatch (gmain.c:2061) ==18821== by 0x54BCD33: g_main_context_iterate (gmain.c:2694) ==18821== by 0x54BD057: g_main_loop_run (gmain.c:2898)
*** Bug 482125 has been marked as a duplicate of this bug. ***
*** Bug 483467 has been marked as a duplicate of this bug. ***
*** Bug 482102 has been marked as a duplicate of this bug. ***
*** Bug 485046 has been marked as a duplicate of this bug. ***
*** Bug 485061 has been marked as a duplicate of this bug. ***
*** Bug 491186 has been marked as a duplicate of this bug. ***
*** Bug 494811 has been marked as a duplicate of this bug. ***
*** Bug 492427 has been marked as a duplicate of this bug. ***
*** Bug 497383 has been marked as a duplicate of this bug. ***
*** Bug 497773 has been marked as a duplicate of this bug. ***
*** Bug 506980 has been marked as a duplicate of this bug. ***
*** Bug 503497 has been marked as a duplicate of this bug. ***
*** Bug 500491 has been marked as a duplicate of this bug. ***
*** Bug 489288 has been marked as a duplicate of this bug. ***
*** Bug 510005 has been marked as a duplicate of this bug. ***
*** Bug 511408 has been marked as a duplicate of this bug. ***
*** Bug 511660 has been marked as a duplicate of this bug. ***
*** Bug 512688 has been marked as a duplicate of this bug. ***
*** Bug 513718 has been marked as a duplicate of this bug. ***
*** Bug 514322 has been marked as a duplicate of this bug. ***
*** Bug 516173 has been marked as a duplicate of this bug. ***
*** Bug 516504 has been marked as a duplicate of this bug. ***
*** Bug 517454 has been marked as a duplicate of this bug. ***
*** Bug 517975 has been marked as a duplicate of this bug. ***
*** Bug 518959 has been marked as a duplicate of this bug. ***
I so hate seeing all those duplicates coming in and nobody from Gnome handling the bug. It's already marked as HIGH priority, yet nobody has been working on it since quite some time... It's a very annoying bug for me (because evolution-data-server leaks memory and I have to kill it every few days and every time the panel crashes, and when the panel crashes I loose most of the stuff which appears in the systray). I'd be ready to put 10€ on a bounty if I knew an easy way to do this (transfer to a paypal/whatever account could work). Please handle this bug. It's very easy to reproduce but seems to require a good knowledge to understand what's happening.
(In reply to comment #40) > I so hate seeing all those duplicates coming in and nobody from Gnome handling > the bug. It's already marked as HIGH priority, yet nobody has been working on > it since quite some time... I did look at it and couldn't find the bug after a quick look. I also couldn't reproduce the bug, which doesn't help. I surely will look at it again, but I didn't have a lot of time for hacking in the past few months...
*** Bug 519566 has been marked as a duplicate of this bug. ***
*** Bug 519991 has been marked as a duplicate of this bug. ***
*** Bug 516939 has been marked as a duplicate of this bug. ***
*** Bug 520536 has been marked as a duplicate of this bug. ***
Couple things I've found out 1. The bug only occurs if you first open the calendar window, then before calling evolution --force-shutdown close the calendar window From this I looked into calendar_window_destroy, and it looks as though it clears all of the pointers and stuff. Now this method is called when the calendar window is hidden. So what I think happens is when you call evolution --force-shutdown it calls the backend_died_cb, but in calendar_window_destroy the calendar data was freed. I tested this by having calendar_window_destroy not doing anything (in other words it does not free the pointers), and the bug does not occur. With that in mind either we can keep all of the data in memory instead of freeing it when the calendar is closed or make it so the callbacks are not called when the calendar is hidden. I just started playing around with the gnome api so I'm not sure if any of the above is possible.
Created attachment 106951 [details] [review] potential fix to bug 378854 It seems as though the clock only crashes if it is closed when the command evolution --force-shutdown is called, so before running the backend_died_cb handler it checks to make sure if the calendar is even open by checking the loaded variable. Not sure if this is the best way to fix this bug but it seems to work with no side effects in my limited testing
I tried the patch of Anthony, and it seems to work fine here too. Thanks a lot Anthony.
Am I allowed to commit it or do I have to have a maintainer do it?
*** Bug 524139 has been marked as a duplicate of this bug. ***
*** Bug 525783 has been marked as a duplicate of this bug. ***
*** Bug 500329 has been marked as a duplicate of this bug. ***
*** Bug 526474 has been marked as a duplicate of this bug. ***
*** Bug 526597 has been marked as a duplicate of this bug. ***
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
*** Bug 527400 has been marked as a duplicate of this bug. ***
*** Bug 528731 has been marked as a duplicate of this bug. ***
Can someone backport this to the 2.22 branch? It's driving me potty. :)
Sam: it's already in 2.22.1.
I'm still seeing the crash in 2.22.1. I'll try to get a backtrace.
Scratch that; the machine that it crashed on was running 2.22.0. Thanks! :)
*** Bug 529493 has been marked as a duplicate of this bug. ***
*** Bug 530493 has been marked as a duplicate of this bug. ***
*** Bug 530820 has been marked as a duplicate of this bug. ***
*** Bug 531081 has been marked as a duplicate of this bug. ***
*** Bug 532293 has been marked as a duplicate of this bug. ***
*** Bug 533352 has been marked as a duplicate of this bug. ***
*** Bug 533580 has been marked as a duplicate of this bug. ***
*** Bug 536458 has been marked as a duplicate of this bug. ***
*** Bug 537878 has been marked as a duplicate of this bug. ***
*** Bug 538045 has been marked as a duplicate of this bug. ***
*** Bug 539037 has been marked as a duplicate of this bug. ***
*** Bug 539300 has been marked as a duplicate of this bug. ***
*** Bug 539367 has been marked as a duplicate of this bug. ***
*** Bug 551801 has been marked as a duplicate of this bug. ***
https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/276783 is a similar crash on GNOME 2.24 "1) Connected to a wireless network 2) Had gnome calendar applet open, evolution open to calendar page. 3) Closed lid on laptop, entered suspend-to-ram 4) Docked laptop, resumed 5) NetworkManager switched to wired connection 6) Evolution and gnome calendar applet were unresponsive. Gnome panels were also unresponsive 7) Killed Evolution at "unresponsive program" prompt 8) "ps aux | grep evo" showed evolution-data-server-2.24 evolution-exchange-storage evolution-alarm-notify still running 9) Because panels were unresponsive, did a "killall evolution-data-server-2.24 evolution-exchange-storage evolution-alarm-notify" 10) Moments later, gnome panel crashed."
No duplicates for a long time.
So has this happened to anybody recently? (NEEDINFO)
I do a --force-shutdown fairly regularly and have not had it take out the panel for a very long time.
Closing the bug as per comment#80. Please feel free to reopen the bug if the problem still occurs with a newer version of GNOME 2.28.2 or later, thanks.