GNOME Bugzilla – Bug 577627
Crash in camel_partition_table_lookup, text_index_has_name at camel-text-index.c line 583
Last modified: 2013-08-23 18:05:12 UTC
What were you doing when the application crashed? Reading mail. Distribution: openSUSE 11.1 (i586) Gnome Release: 2.26.0 (null) (SUSE) BugBuddy Version: 2.26.0 System: Linux 2.6.27.19-3.2-default #1 SMP 2009-02-25 15:40:44 +0100 i686 X Vendor: The X.Org Foundation X Vendor Release: 10502000 Selinux: No Accessibility: Disabled GTK+ Theme: Gilouche Icon Theme: oxygen GTK+ Modules: canberra-gtk-module, gnomebreakpad Memory status: size: 268967936 vsize: 268967936 resident: 49950720 share: 25677824 rss: 49950720 rss_rlim: 18446744073709551615 CPU usage: start_time: 1238605723 rtime: 1099 utime: 1025 stime: 74 cutime:1 cstime: 1 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/evolution' [?1034h[Thread debugging using libthread_db enabled] [New Thread 0xb4e14b90 (LWP 10842)] [New Thread 0xaa552b90 (LWP 10821)] [New Thread 0xac7bfb90 (LWP 10594)] [New Thread 0xa9b9eb90 (LWP 10593)] [New Thread 0xabfbeb90 (LWP 10576)] [New Thread 0xab7bdb90 (LWP 10546)] [New Thread 0xacfc0b90 (LWP 10543)] [New Thread 0xb33ffb90 (LWP 10542)] [New Thread 0xb3d84b90 (LWP 10540)] [New Thread 0xb4613b90 (LWP 10538)] [New Thread 0xb5615b90 (LWP 10535)] 0xffffe430 in __kernel_vsyscall ()
+ Trace 214091
Thread 3 (Thread 0xaa552b90 (LWP 10821))
---- Critical and fatal warnings logged during execution ---- ** camel **: camel_object_unhook_event: assertion `CAMEL_IS_OBJECT (obj)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unhook_event: assertion `CAMEL_IS_OBJECT (obj)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unhook_event: assertion `CAMEL_IS_OBJECT (obj)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unhook_event: assertion `CAMEL_IS_OBJECT (obj)' failed ** camel **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed ** camel **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed ----------- .xsession-errors --------------------- (evolution:10522): camel-CRITICAL **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:10522): camel-WARNING **: Trying to check junk data is OBJECT 'CamelObject' (evolution:10522): camel-CRITICAL **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed (evolution:10522): camel-CRITICAL **: camel_object_unhook_event: assertion `CAMEL_IS_OBJECT (obj)' failed (evolution:10522): camel-WARNING **: Trying to check junk data is OBJECT 'CamelObject' (evolution:10522): camel-CRITICAL **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed (evolution:10522): camel-CRITICAL **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed Cannot access memory at address 0xc Cannot access memory at address 0xc --------------------------------------------------
Seems similar to bug #576539, only not deleting, but searching here. are you able to reproduce it anyhow reliably?
It isn't reproduced recently. That was a random crash while reading a mail. I don't even remember the mail at which it crashed. I'll pots more updates it is reproduced.
*** Bug 618082 has been marked as a duplicate of this bug. ***
last dupe in 2.30.x
Downstream bug report about the same in 2.32.0: https://bugzilla.redhat.com/show_bug.cgi?id=649998
bug 637305 looks related
*** Bug 638779 has been marked as a duplicate of this bug. ***
*** Bug 638952 has been marked as a duplicate of this bug. ***
*** Bug 639160 has been marked as a duplicate of this bug. ***
I get this five or so times per day myself. It started fairly recently (the last month or two) in the 2.32 snapshots. Program received signal SIGSEGV, Segmentation fault.
+ Trace 225490
Thread 2714753904 (LWP 23908)
I'm seeing the same for some weeks now, I can't use evolution any longer because it always happens while polling mail. Using evolution 2.32.2-2 on debian unstable. Program received signal SIGSEGV, Segmentation fault.
+ Trace 226661
Thread 2897214320 (LWP 29951)
Forgot to mention, I'm using the maildir backend, which is constantly "Checking folder consistency" which takes almost forever in some folders. No idea if that's in any way related, but it happend to crash while doing that too, not only when polling.
Try to clear ibex/index files from your ~/.local/share/evolution/mail/... folders (the best only for the one it happened in), if they are corrupted after a crash, then this will recreate them. I've nothing else to advice at the moment.
My mail folders are in ~/Mail not in ~/.local/share/evolution I suppose you mean the *.ibex.index files there, or do i also delete the *.ibex.index.data files?
I meant anything with ibex or index in the extension of the file name. Just do not delete them, but move them away, in case something will go worse, you will have files to return back. In other words, you can delete all generated files, they will be recreated the next start, when needed. See also: http://live.gnome.org/Evolution/FAQ#Why_do_I_get_an_error_.22Summary_and_folder_mismatch.2C_even_after_a_sync.22.3F
*** Bug 648453 has been marked as a duplicate of this bug. ***
*** Bug 651076 has been marked as a duplicate of this bug. ***
*** Bug 651304 has been marked as a duplicate of this bug. ***
*** Bug 651484 has been marked as a duplicate of this bug. ***
*** Bug 651742 has been marked as a duplicate of this bug. ***
Closing as OBSOLETE since the stack trace is too old to be useful now. Reopen the bug and update the version field if this crash still occurs in Evolution 3.8 or later.