GNOME Bugzilla – Bug 273699
Crash starting evolution-alarm-notify manually if it already runs
Last modified: 2013-09-13 00:52:57 UTC
Distribution: Debian 3.1 Package: Evolution Priority: Normal Version: GNOME2.10.0 2.2.0 Gnome-Distributor: Ubuntu Synopsis: evolution-alarm-notify has terminated unexpectedly Bugzilla-Product: Evolution Bugzilla-Component: Miscellaneous Bugzilla-Version: 2.2.0 BugBuddy-GnomeVersion: 2.0 (2.10.0) Description: Description of the crash: Steps to reproduce the crash: 1. install base warty system 2. dist upgrade to hoary 3. reboot machine and upon login the evolution-alarm-notify process crashes unexpectedly Expected Results: It shouldn't do this! How often does this happen? Every login Additional Information: Debugging Information: Backtrace was generated from '/usr/libexec/evolution-alarm-notify' Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 183002562880 (LWP 8396)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0x0000002a99337f86 in waitpid () from /lib/libc.so.6
+ Trace 56883
Thread 1 (Thread 183002562880 (LWP 8396))
Unknown reporter: matthew.overy@blueyonder.co.uk, changed to bugbuddy-import@ximian.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
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.
No response--closing; feel free to reopen if you can provide the requested information.
*** Bug 321332 has been marked as a duplicate of this bug. ***
*** Bug 321659 has been marked as a duplicate of this bug. ***
*** Bug 328730 has been marked as a duplicate of this bug. ***
*** Bug 330128 has been marked as a duplicate of this bug. ***
REOPENing and Confirming due to duplicates. Setting proper crasher priority. Note: All duplicates are Evo 2.2.x.
*** Bug 326765 has been marked as a duplicate of this bug. ***
*** Bug 302084 has been marked as a duplicate of this bug. ***
*** Bug 325488 has been marked as a duplicate of this bug. ***
*** Bug 328511 has been marked as a duplicate of this bug. ***
Some more duplicates. Note: One of the duplicates is Evo 2.0.x, that last two duplucates are actually Evolution 2.4.x!
*** Bug 330451 has been marked as a duplicate of this bug. ***
Another 2.4.x duplicate. Correcting Component, setting Target Milestone.
*** Bug 324951 has been marked as a duplicate of this bug. ***
The stack traces not informative. Please provide a better trace. Also try upgrading to the version 2.4.2.1 which has a similar bug 323955 fixed. Providing the warnings which appear by running evolution-alarm-notify from terminal will also be very useful.
I worked on this some of the crashes in alarm daemon. I saw it happening, this is because creation of a bonobo factory fails and a g_error log will be displayed in the terminal, "Could not create the alarm notify service factory". Reopening.
would be nice to know if this is fixed in CVS head by srini's EThread alarm notify improvements... comments?
Andre if chen is right, this should happen, if some one starts alarm notify manually and it is running automatically. this is not yet fixed.
this STILL happens in 2.11, folks!
+ Trace 141311
----------- .xsession-errors (42 sec old) --------------------- alarm-queue.c:551 (load_alarms) - Setting Call backs alarm-queue.c:2020 (alarm_queue_add_async) - 0x9e2e030 alarm-queue.c:585 (load_alarms_for_today) - From Sun Jun 3 00:00:00 2007 to Sun Jun 3 00:00:00 2007 alarm-queue.c:522 (load_alarms) alarm-queue.c:551 (load_alarms) - Setting Call backs alarm-queue.c:2020 (alarm_queue_add_async) - 0x9e36720 alarm-queue.c:585 (load_alarms_for_today) - From Sun Jun 3 00:00:00 2007 to Sun Jun 3 00:00:00 2007 alarm-queue.c:522 (load_alarms) alarm-queue.c:551 (load_alarms) - Setting Call backs alarm-notify.c:316 (cal_opened_cb) file:///home/jik/.evolution/memos/local/system - Calendar Status 0 alarm-queue.c:2020 (alarm_queue_add_async) - 0x9e39760 alarm-queue.c:585 (loa --------------------------------------------------
*** Bug 443579 has been marked as a duplicate of this bug. ***
*** Bug 412626 has been marked as a duplicate of this bug. ***
*** Bug 374166 has been marked as a duplicate of this bug. ***
*** Bug 363523 has been marked as a duplicate of this bug. ***
Created attachment 92037 [details] [review] proposed hacky patch for evolution; this is a hacky patch, it only changed g_error to g_warning when factory could not be created, and changed a string to "Could not create the alarm notify service factory, maybe it's already running...". I did want to do it properly, with error code checking, but the bonobo didn't propagate this error code and it could not be rewrote, because used functions touch private member of factory in bonobo_generic_factory_construct. I'm not sure if srag will not to rewrite this to not use bonobo as he mentioned at other place, so it will be fixed in better way.
Milan. I think it is not a error condition at all. If it is already running you cause a warning and quit safely. I think this is perfectly OK. Also It would be fine to return 0 in this case as it is not a real error.
there's just a problem that you don't know if it fails because of real error or because it is already running, so I prefer to not return 0, just to indicate _possible_ error.
go ahead :)
Committed to trunk, Committed revision 33843.
*** Bug 509466 has been marked as a duplicate of this bug. ***