GNOME Bugzilla – Bug 404709
crash in Evolution: Trying to add an appoint...
Last modified: 2007-02-18 12:04:37 UTC
What were you doing when the application crashed? Trying to add an appointment without a specific time Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 313098240 vsize: 313098240 resident: 36139008 share: 20766720 rss: 36139008 rss_rlim: -1 CPU usage: start_time: 1170701846 rtime: 752 utime: 706 stime: 46 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/evolution-2.8' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46914399776112 (LWP 5910)] [New Thread 1132489040 (LWP 6005)] [New Thread 1141147984 (LWP 5947)] [New Thread 1115703632 (LWP 5928)] [New Thread 1107310928 (LWP 5927)] [New Thread 1098918224 (LWP 5922)] [New Thread 1090525520 (LWP 5921)] [New Thread 1082132816 (LWP 5917)] (no debugging symbols found) 0x00002aab17d635cf in waitpid () from /lib/libc.so.6
+ Trace 108250
Thread 8 (Thread 1082132816 (LWP 5917))
Thread 7 (Thread 1090525520 (LWP 5921))
Thread 6 (Thread 1098918224 (LWP 5922))
Thread 5 (Thread 1107310928 (LWP 5927))
Thread 4 (Thread 1115703632 (LWP 5928))
Thanks for taking the time to report this bug. Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Finally got this to crash again. Again I was adding an appointment. I entered the info into the bar space on the calendar, hit return and then immediately tried to edit the same appointment. Here are the additional stac traces (I hope); if you need more I'll try to help. Craig Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 370180096 vsize: 370180096 resident: 53760000 share: 24584192 rss: 53760000 rss_rlim: -1 CPU usage: start_time: 1171582249 rtime: 2035 utime: 1907 stime: 128 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/evolution-2.8' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 47589714681200 (LWP 10412)] [New Thread 1107310928 (LWP 10901)] [New Thread 1141147984 (LWP 10485)] [New Thread 1132489040 (LWP 10483)] [New Thread 1115703632 (LWP 10481)] [New Thread 1098918224 (LWP 10425)] [New Thread 1090525520 (LWP 10424)] [New Thread 1082132816 (LWP 10420)] 0x00002b4853bde5cf in waitpid () from /lib/libc.so.6
+ Trace 111140
Thread 8 (Thread 1082132816 (LWP 10420))
Thread 7 (Thread 1090525520 (LWP 10424))
Thread 6 (Thread 1098918224 (LWP 10425))
Thread 5 (Thread 1115703632 (LWP 10481))
Thread 4 (Thread 1132489040 (LWP 10483))
Unfortunately, that's a bit better, but still not vastly useful. If you see a stacktrace from Bug Buddy with no "<signal handler called>" and lots of "killpg"'s followed by "??" items, then it means that Bug Buddy has got a bit confused... One way around this if you've got a repeatable way to trigger the bug is to get a trace from gdb directly. There's a guide at http://live.gnome.org/GettingTraces/Details#gdb-not-yet-running that says how to do this. Should help us resolve this one properly. Thanks!
Ok. I can repeatedly crash the program by entering something in the appointment space and then, before hitting return, right click on it. Here is the gdb stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47928729247088 (LWP 5536)] e_cal_popup_target_new_select (eabp=<value optimized out>, model=0x10cdb30, events=0x12b31b0) at e-cal-popup.c:572 572 e-cal-popup.c: No such file or directory. in e-cal-popup.c (gdb) thread apply all bt
+ Trace 111698
Thread 1 (Thread 47928729247088 (LWP 5536))
Ok, looks like it's a duplicate of Bug 342634 which has been resolved. Thanks for your help! *** This bug has been marked as a duplicate of 342634 ***