After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583179 - Evolution crashes when reading folder summary
Evolution crashes when reading folder summary
Status: RESOLVED DUPLICATE of bug 573125
Product: Evolution Exchange
Classification: Deprecated
Component: Connector
2.26.x
Other All
: High critical
: ---
Assigned To: Connector Maintainer
Ximian Connector QA
Depends on:
Blocks:
 
 
Reported: 2009-05-19 08:57 UTC by Anton Keks
Modified: 2009-07-13 09:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
full stacktrace of the crash (11.67 KB, text/plain)
2009-05-21 06:29 UTC, Anton Keks
Details

Description Anton Keks 2009-05-19 08:57:56 UTC
Steps to reproduce:
After some Ubuntu updates (evolution 2.26.1-0ubuntu2), evolution started crashing on startup. Downgrading the package didn't help, so maybe upgrade was just a coincidence, so I am posting this here.

Program received signal SIGSEGV, Segmentation fault.

Stack trace:

Thread 1 (Thread 0xb6155770 (LWP 9019))

  • #0 __kernel_vsyscall
  • #1 select
    from /lib/tls/i686/cmov/libc.so.6
  • #2 ??
    from /usr/lib/libxcb.so.1
  • #3 xcb_wait_for_reply
    from /usr/lib/libxcb.so.1
  • #4 _XReply
    from /usr/lib/libX11.so.6
  • #5 XQueryPointer
    from /usr/lib/libX11.so.6
  • #6 _gdk_windowing_window_get_pointer
    at /build/buildd/gtk+2.0-2.16.1/gdk/x11/gdkwindow-x11.c line 3357
  • #7 IA__gdk_window_get_pointer
    at /build/buildd/gtk+2.0-2.16.1/gdk/gdkwindow.c line 3333
  • #8 gtk_tree_view_bin_expose
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtktreeview.c line 4695
  • #9 gtk_tree_view_expose
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtktreeview.c line 4959
  • #10 _gtk_marshal_BOOLEAN__BOXED
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmarshalers.c line 84
  • #11 g_type_class_meta_marshal
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 878
  • #12 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #13 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3285
  • #14 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 2990
  • #15 IA__g_signal_emit
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3037
  • #16 gtk_widget_event_internal
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkwidget.c line 4761
  • #17 IA__gtk_main_do_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 1558
  • #18 gdk_window_process_updates_internal
    at /build/buildd/gtk+2.0-2.16.1/gdk/gdkwindow.c line 2611
  • #19 IA__gdk_window_process_all_updates
    at /build/buildd/gtk+2.0-2.16.1/gdk/gdkwindow.c line 2677
  • #20 gtk_container_idle_sizer
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkcontainer.c line 1353
  • #21 gdk_threads_dispatch
    at /build/buildd/gtk+2.0-2.16.1/gdk/gdk.c line 498
  • #22 g_idle_dispatch
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 3922
  • #23 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 1814
  • #24 g_main_context_iterate
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2448
  • #25 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2656
  • #26 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #27 main
    at main.c line 704


Other information:
Comment 1 Anton Keks 2009-05-19 09:01:23 UTC
Or maybe this thread is guilty?

Thread 15 (Thread 0xaf373b90 (LWP 9044))

  • #0 camel_exchange_folder_construct
    at camel-exchange-folder.c line 1050
  • #1 exchange_get_folder
    at camel-exchange-store.c line 516
  • #2 camel_store_get_folder
    at camel-store.c line 345
  • #3 mail_tool_uri_to_folder
    at mail-tools.c line 331
  • #4 get_folder_exec
    at mail-ops.c line 1214
  • #5 mail_msg_proxy
    at mail-mt.c line 520
  • #6 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.20.1/glib/gthreadpool.c line 265
  • #7 g_thread_create_proxy
    at /build/buildd/glib2.0-2.20.1/glib/gthread.c line 635
  • #8 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #9 clone
    from /lib/tls/i686/cmov/libc.so.6

Comment 2 Akhil Laddha 2009-05-20 04:44:52 UTC
It will be good if you can provide full traces.    
Comment 3 Anton Keks 2009-05-21 06:29:26 UTC
Created attachment 135068 [details]
full stacktrace of the crash

always reproducible
Comment 4 Anton Keks 2009-05-25 18:16:29 UTC
Any ideas or workarounds?

Milan, maybe you can help?
Comment 5 Milan Crha 2009-05-25 21:03:02 UTC
I guess those updates might be related. Try update all evolution-data-server, evolution, evolution-exchange to the latest versions, and it, with a bit of luck, will start to work. If not, what's on the console, when you run evolution there?
Comment 6 Anton Keks 2009-05-26 21:01:00 UTC
I am fully up-to-date, at least according to the Ubuntu maintainers.

I can even reproduce the bug in evolution's offline mode: all I have to do is navigate to my Inbox folder, so this time it is not related to communication with the server, but probably with reading of some cached data from the disk.

The console is not very informative:

$ evolution --offline
** (evolution:5483): DEBUG: mailto URL command: evolution %s
** (evolution:5483): DEBUG: mailto URL program: evolution
** (evolution:5483): DEBUG: EI: SHELL STARTUP
Segmentation fault (core dumped)
Comment 7 Milan Crha 2009-05-27 11:17:28 UTC
In that case, it seems your folders.db summary is heavily broken. What happens when you run this command, please:
   $ sqlite3 ~/.evolution/mail/exchange/<account>/folders.db "SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'personal/Deleted Items' WHERE uid = '000002396d06'"

(it's one long line, not 4; also, change there that <account> with the folder you've there).

I guess it'll crash too, if yes, then move that folders.db file somewhere else (for debugging) and evolution will recreate it next start.
Comment 8 Anton Keks 2009-05-30 11:34:41 UTC
The renaming of folders.db helped - Evolution recreated it (although not yet fully - I have unchecked the 'check for mail in all folders' for now), and I can read my mail again.

The select query above returns a perfectly normal result when executed from sqlite3. I wasn't able to find any corrupt records in the old folders.db. So it is still some weird evolution bug...
Comment 9 Milan Crha 2009-06-01 10:23:17 UTC
Would you mind to send me the broken folders.db in private (to the bugzilla mail), in some compress form, so I would try to look at its content for some simple corruptions I would think of? I really do not care for the message infos you've there (there are stored all the information shown in the message list tree (above the message preview, if you've turned that on).
Comment 10 Anton Keks 2009-06-01 21:19:44 UTC
Sent!
Comment 11 Milan Crha 2009-06-02 08:45:47 UTC
Thanks. Using your folders.db in my account also crashes evolution, though in a different folder, for me in Inbox.

I found that there is a command for checking integrity of a folders.db file:
   $ sqlite3 folders.db "PRAGMA integrity_check;"
and it is supposed to either return "ok" or list of errors, where for your file it returned:
   rowid 8199 missing from index sqlite_autoindex_personal/Inbox_1
   rowid 13650 missing from index sqlite_autoindex_personal/Inbox_1

so I ran the reindex on it:
   $ sqlite3 folders.db "REINDEX 'personal/inbox';"

and then even evolution was happy with the file. I guess the database corruption was caused by some previous evolution crash (as we are not using immediate writes with fsync calls now).

I'm afraid that we cannot do more with this, nothing else then fix other bugs which causes crashes and could potentially break folders.db files.
What do you think?
Comment 12 Anton Keks 2009-06-03 21:06:36 UTC
Thanks a lot for the investigation!

As it probably would be hard to eliminate 100% all the causes when the db can be corrupted, maybe it makes sense to detect this corruption somehow and recreate the DB instead?

Otherwise it is very hard for end-users to recover from such situation, making them think that evolution is too unstable for their use.

I am just speculating here, do you have any idea how this kind of crash could be intercepted in the code? Maybe some logic in the signal handler?
Comment 13 Milan Crha 2009-06-04 09:26:19 UTC
(In reply to comment #12)
> As it probably would be hard to eliminate 100% all the causes when the db can
> be corrupted, maybe it makes sense to detect this corruption somehow and
> recreate the DB instead?

Yeah, that might be doable too, some integrity checks on start or something. I believe srag has something with this, in some other bug hopefully, thus CC'ing him here.
Comment 14 Milan Crha 2009-07-13 09:41:29 UTC
I recalled the same is discussed within bug #573125, thus marking this one as a duplicate.

*** This bug has been marked as a duplicate of 573125 ***