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 664670 - [regression] evolution doesn't exit properly
[regression] evolution doesn't exit properly
Status: RESOLVED DUPLICATE of bug 664639
Product: evolution
Classification: Applications
Component: general
3.4.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-11-23 19:58 UTC by David Ronis
Modified: 2013-09-13 01:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Ronis 2011-11-23 19:58:59 UTC 
I'm using today's git/master for evo, eds, etc.   When I try to exit evo, the UI disappears but evo keeps on running.    I killed it with 'evolution --force-shutdown' which resulted in a core file.

Here's a backtrace:

Core was generated by `evolution'.
Program terminated with signal 3, Quit.

+ Trace 229113

Thread 16 (Thread 0x9c8ffb70 (LWP 6301))

  • #0 open
    from /lib/libc.so.6
  • #1 _IO_new_file_fopen
    from /lib/libc.so.6
  • #2 __fopen_internal
    from /lib/libc.so.6
  • #3 fopen64
    from /lib/libc.so.6
  • #4 camel_object_state_write
    at camel-object.c line 443
  • #5 local_folder_synchronize_sync
    at camel-local-folder.c line 413
  • #6 camel_folder_synchronize_sync
    at camel-folder.c line 3613
  • #7 store_synchronize_sync
    at camel-store.c line 392
  • #8 camel_store_synchronize_sync
    at camel-store.c line 2970
  • #9 store_synchronize_thread
    at camel-store.c line 955
  • #10 run_in_thread
    at gsimpleasyncresult.c line 838
  • #11 io_job_thread
    at gioscheduler.c line 177
  • #12 g_thread_pool_thread_proxy
    at gthreadpool.c line 317
  • #13 g_thread_proxy
    at gthread.c line 801
  • #14 start_thread
    from /lib/libpthread.so.0
  • #15 clone
    from /lib/libc.so.6

Thread 15 (Thread 0x9e3ffb70 (LWP 6300))

  • #0 read
    from /lib/libpthread.so.0
  • #1 seekAndRead
    at sqlite3.c line 27572
  • #2 unixRead
    at sqlite3.c line 27606
  • #3 camel_sqlite3_file_xRead
    at camel-db.c line 192
  • #4 sqlite3OsRead
    at sqlite3.c line 14476
  • #5 sqlite3PagerSharedLock
    at sqlite3.c line 42187
  • #6 lockBtree
    at sqlite3.c line 50385
  • #7 sqlite3BtreeBeginTrans
    at sqlite3.c line 50677
  • #8 sqlite3VdbeExec
    at sqlite3.c line 66301
  • #9 sqlite3Step
    at sqlite3.c line 61844
  • #10 sqlite3_step
    at sqlite3.c line 61917
  • #11 sqlite3_step
    at sqlite3.c line 61905
  • #12 sqlite3_exec
    at sqlite3.c line 89119
  • #13 cdb_sql_exec
    at camel-db.c line 414
  • #14 camel_db_write_folder_info_record
    at camel-db.c line 1799
  • #15 camel_vee_folder_sync_headers
    at camel-vee-folder.c line 2454
  • #16 store_synchronize_sync
    at camel-store.c line 396
  • #17 camel_store_synchronize_sync
    at camel-store.c line 2970
  • #18 store_synchronize_thread
    at camel-store.c line 955
  • #19 run_in_thread
    at gsimpleasyncresult.c line 838
  • #20 io_job_thread
    at gioscheduler.c line 177
  • #21 g_thread_pool_thread_proxy
    at gthreadpool.c line 317
  • #22 g_thread_proxy
    at gthread.c line 801
  • #23 start_thread
    from /lib/libpthread.so.0
  • #24 clone
    from /lib/libc.so.6

Thread 14 (Thread 0xa36c7b70 (LWP 6292))

  • #0 fsync
    from /lib/libpthread.so.0
  • #1 full_fsync
    at sqlite3.c line 27838
  • #2 unixSync
    at sqlite3.c line 27930
  • #3 call_old_file_Sync
    at camel-db.c line 68
  • #4 sync_request_thread_cb
    at camel-db.c line 94
  • #5 g_thread_pool_thread_proxy
    at gthreadpool.c line 317
  • #6 g_thread_proxy
    at gthread.c line 801
  • #7 start_thread
    from /lib/libpthread.so.0
  • #8 clone
    from /lib/libc.so.6 






Comment 1


André Klapper





          2011-11-23 22:29:43 UTC
        



Might be a dup, but confirming.






Comment 2


Milan Crha





          2011-11-24 16:14:34 UTC
        



Hmm, I do not see anything special on the backtrace, the only active threads are Thread 14, Thread 15 and Thread 16. Thread 16 is opening one of your local .cmeta files, the Thread 15 is reading through sqlite (interesting that the 'read' function is linked from libpthread, I didn't know it's there. Finally thread 14 is calling fsync, which should flush all file buffers into disk, which can take its time in certain cases. Why it got stuck for you I do not know.






Comment 3


Matthew Barnes





          2011-11-24 16:39:29 UTC
        



I'm gonna close this as a dupe of bug #664639 since that bug has a more useful stacktrace.

I've seen this on occasion too, and it's usually either sqlite taking its sweet time to sync changes to disk or the imapx_parser_thread() stuck in some NSPR call while another thread is waiting to join with it.

Usually if I give it enough time it exits on its own, but it can be on the order of minutes (socket timeout, probably).

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