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 575084 - Crashes with SQLite upgrade from 3.5.x to 3.6.x
Crashes with SQLite upgrade from 3.5.x to 3.6.x
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: BugBuddyBugs
2.24.x (obsolete)
Other All
: High critical
: ---
Assigned To: Evolution Triage Team
Evolution QA team
: 577069 577189 577198 579916 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-03-12 13:55 UTC by Alban Browaeys
Modified: 2009-07-15 05:34 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
proposed eds patch (3.28 KB, patch)
2009-03-30 20:35 UTC, Milan Crha
committed Details | Review

Description Alban Browaeys 2009-03-12 13:55:30 UTC
What were you doing when the application crashed?
Starting evolution (triggered upgrade to sqlite as of switch from 2.22 to 2.24.1). WIth  a lot of errors on the console from the migration:


(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed

(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


em-migrate.c:3012:migrate_to_db: failed to get folder infos 

(evolution:13165): camel-imap-provider-WARNING **: Unable to load summary no such table: Drafts


(evolution:13165): camel-imap-provider-WARNING **: Unable to load summary no such table: INBOX


(...)

(evolution:13165): camel-imap-provider-WARNING **: Unable to load summary no such table: Trash


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate


(evolution:13165): camel-WARNING **: No summary path set. Unable to migrate

addressbook_migrate (2.22.0)
** (evolution:13165): DEBUG: mailto URL command: evolution %s
** (evolution:13165): DEBUG: mailto URL program: evolution

(evolution:13165): evolution-mail-WARNING **: VFolder of VFolders not supporting. Ignoring loading this vfolder as a subfolder


(evolution:13165): evolution-mail-WARNING **: Failed to refresh folders: Impossible d'obtenir le dossier « /home/prahal/Mail/debian » : ce n'est pas un répertoire Maildir.
e-data-server-ui-Message: Received a password from keyring 'default'. But looking for the password from 'login' keyring



Distribution: Debian squeeze/sid
Gnome Release: 2.24.2 2009-01-04 (Debian)
BugBuddy Version: 2.24.2

System: Linux 2.6.29-rc7-00003-g559595a #51 SMP Mon Mar 9 08:57:50 CET 2009 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10599902
Selinux: Permissive
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: yasis

Memory status: size: 370573312 vsize: 370573312 resident: 94134272 share: 22224896 rss: 94134272 rss_rlim: 18446744073709551615
CPU usage: start_time: 1236865565 rtime: 9144 utime: 7223 stime: 1921 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

[Thread debugging using libthread_db enabled]
[New Thread 0xa4dffb90 (LWP 15208)]
[New Thread 0xa8f6eb90 (LWP 15207)]
[New Thread 0xa6f6ab90 (LWP 15133)]
[New Thread 0xa6769b90 (LWP 15061)]
[New Thread 0xaa771b90 (LWP 15009)]
[New Thread 0xa9f70b90 (LWP 15007)]
0xffffe424 in __kernel_vsyscall ()

Thread 2 (Thread 0xa4dffb90 (LWP 15208))

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S line 136
  • #2 _L_lock_89
    from /lib/i686/cmov/libpthread.so.0
  • #3 __pthread_mutex_lock
    at pthread_mutex_lock.c line 86
  • #4 segv_redirect
    at main.c line 423
  • #5 <signal handler called>
  • #6 ??
    from /usr/lib/libsqlite3.so.0
  • #7 ??
  • #8 ??
  • #9 ??
  • #10 ??
    from /usr/lib/libcamel-1.2.so.14
  • #11 ??
  • #12 ??
  • #13 ??
  • #14 camel_sqlite3_file_xLock
    at camel-db.c line 280
  • #15 camel_sqlite3_file_xCheckReservedLock
    at camel-db.c line 283
  • #16 ??
    from /usr/lib/libsqlite3.so.0
  • #17 ??
  • #18 ??
  • #19 ??


----------- .xsession-errors (154691 sec old) ---------------------
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
ERROR: Couldn't attach to DCOP server!
...Too much output, ignoring rest...
--------------------------------------------------
Comment 1 Alban Browaeys 2009-03-12 14:37:22 UTC
Note that the issue is fixed by downgrading sqlite3 from 3.6.10 to 3.5.9.
Comment 2 Milan Crha 2009-03-27 16:20:03 UTC
I think it's "fixed" only because it didn't migrate again. Or did it migrate again for you next start?

Please note that the migration code had been improved since 2.24.1, I would recommend you to upgrade to the latest 2.24.5, or even better 2.26.0.
Comment 3 Daniel Leidert 2009-03-30 09:13:19 UTC
Unfortunately 2.24.5 shows the same issue here on my Debian Sid box. Evolution crashes in random situations (usually during exit). The next start then directly  triggers a segmentation fault [1][2][3] (so I think the backtrace provided in [3] is probably only partially helpful). I have some saved states of my .evolution folder and working a bit with evolution (removing some messages and changing the ordering of folders) then usually leads to a crash then leading to the segmentation fault when trying to start evolution. I will try to provide a backtrace. The combination of sqlite3 3.6.10 and evolution 2.24.x is really unstable (at least on my box).

[1] http://bugs.debian.org/519428
[2] http://bugs.debian.org/521752
[3] http://bugs.debian.org/521608
Comment 4 Milan Crha 2009-03-30 19:59:00 UTC
Aah, I think I got it, from the [3] above. The reason is the API changed in SQLite. Evolution-Data-Server is checking SQLite version in compile time, and even it doesn't link to it statically, it uses a function signature by the version obtained during compile.
Comment 5 Milan Crha 2009-03-30 20:35:57 UTC
Created attachment 131730 [details] [review]
proposed eds patch

for evolution-data-server;

Check for actual SQLite3 version in runtime to call xCheckReservedLock with correct number parameters as expected by the actual SQLite3 version it is running, not was compiled.

Quite hacky, though. SQLite3 documentation is quite strict about compiled and running versions.
Comment 6 Josselin Mouette 2009-03-31 19:41:46 UTC
(In reply to comment #5)
> Quite hacky, though. 

Yeah, that’s scary.

I’d say we should just bump the build-time requirement on sqlite3 to 3.6 and get rid of the 3.5, instead.
Comment 7 Daniel Leidert 2009-04-01 17:56:11 UTC
*** Bug 577189 has been marked as a duplicate of this bug. ***
Comment 8 Akhil Laddha 2009-04-06 06:48:30 UTC
*** Bug 577069 has been marked as a duplicate of this bug. ***
Comment 9 Srinivasa Ragavan 2009-04-07 06:54:00 UTC
Josselin, we can ask for version bump in 2.27 cycle. But till then, we can take the patch in 
Comment 10 Milan Crha 2009-04-07 12:06:01 UTC
Committed to trunk. Committed revision 10199.
Comment 11 Milan Crha 2009-04-20 10:09:33 UTC
*** Bug 577198 has been marked as a duplicate of this bug. ***
Comment 12 Chenthill P 2009-06-03 09:08:01 UTC
I will be sending a mail to the release-team on it today. So to confirm on the reasons for the version bump. 
1) Api change in xCheckReservedLock method.
2) Most of the distributions have sqlite 3.6 

Milan, I hope you have tested evolution against 3.6 and find that its functioning properly.

Am I missing anything else ?
Comment 13 Akhil Laddha 2009-07-15 05:34:41 UTC
*** Bug 579916 has been marked as a duplicate of this bug. ***