GNOME Bugzilla – Bug 356484
crash in Evolution: The application was aski...
Last modified: 2006-09-18 19:57:13 UTC
What were you doing when the application crashed? The application was asking for account passwords every 10 minutes checking for mail. Remember password was already checked. I allowed it to repeat several times. I finally canceled both then went to close evolution as it crashed. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.0 2006-09-04 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 156323840 vsize: 0 resident: 156323840 share: 0 rss: 36184064 rss_rlim: 0 CPU usage: start_time: 1158556189 rtime: 0 utime: 743 stime: 0 cutime:689 cstime: 0 timeout: 54 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/evolution-2.8' (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 -1231989072 (LWP 17216)] [New Thread -1266476128 (LWP 17249)] [New Thread -1274868832 (LWP 17234)] [New Thread -1313043552 (LWP 17233)] [New Thread -1292158048 (LWP 17229)] [New Thread -1283298400 (LWP 17228)] [New Thread -1258083424 (LWP 17224)] [New Thread -1249690720 (LWP 17223)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 72619
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. Also, are you able to reproduce this?
Yes the bug is reproducible, by 1. opening evolution 2. closing evolution Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1232505168 (LWP 8019)] 0x00000000 in ?? () (gdb) thread apply all bt
+ Trace 72678
Thread 1 (Thread -1232505168 (LWP 8019))
This stack trace seems to be more verbose. I'm not sure if that is good or not but here you go. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.0 2006-09-04 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 123166720 vsize: 0 resident: 123166720 share: 0 rss: 26284032 rss_rlim: 0 CPU usage: start_time: 1158603238 rtime: 0 utime: 217 stime: 0 cutime:202 cstime: 0 timeout: 15 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/evolution-2.8' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1232324944 (LWP 8592)] [New Thread -1314722912 (LWP 8608)] [New Thread -1314456672 (LWP 8607)] [New Thread -1293952096 (LWP 8604)] [New Thread -1258419296 (LWP 8603)] [New Thread -1277166688 (LWP 8602)] [New Thread -1285559392 (LWP 8599)] [New Thread -1266812000 (LWP 8597)] [New Thread -1250026592 (LWP 8595)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 72679
Thread 1 (Thread -1232324944 (LWP 8592))
Thanks for the fast response and the debugging symbols. :) This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 330157 ***
Also... (In reply to comment #3) > This stack trace seems to be more verbose. I'm not sure if that is good or not > but here you go. Yes, that stacktrace was perfect. :) Thanks again. Just a note, since I am suffering from that crash myself for quite a while already: This crash is pretty harmless. The only data that may get lost is meta data in the IMAP case -- like read/unread status and such. However, there is an easy workaround for this. Since this data is synced to the server on leaving the folder, one can easily and effectively prevent any (meta) data loss at all by simply "switching forth and back". Actally, just switching the mail folder once before closing Evo will do. HTH