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 567654 - Evolution dies with SIGSEGV on vee_get_message()
Evolution dies with SIGSEGV on vee_get_message()
Status: RESOLVED INCOMPLETE
Product: evolution
Classification: Applications
Component: Mailer
2.26.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[vfolders]
: 568448 568452 568549 569421 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-13 20:53 UTC by C de-Avillez
Modified: 2011-06-02 05:26 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
valgrind log (429.58 KB, text/plain)
2009-01-19 16:28 UTC, C de-Avillez
  Details
Don't strdup when it should be just str-reffed (463 bytes, patch)
2009-01-22 04:40 UTC, Srinivasa Ragavan
committed Details | Review
valgrind log (160.24 KB, text/plain)
2009-01-23 03:05 UTC, C de-Avillez
  Details

Description C de-Avillez 2009-01-13 20:53:13 UTC
Started happening today, on trunk. I left Evo running for a while, and got back to find it gone. Ran a GDB on the core:

(gdb) bt full
  • #0 vee_get_message
    at ../../../evolution-data-server/camel/camel-vee-folder.c line 647
  • #1 camel_folder_get_message
    at ../../../evolution-data-server/camel/camel-folder.c line 1148
  • #2 get_message_exec
    at ../../../evolution/mail/mail-ops.c line 1824
  • #3 mail_msg_proxy
    at ../../../evolution/mail/mail-mt.c line 520
  • #4 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.19.4/glib/gthreadpool.c line 265
  • #5 g_thread_create_proxy
    at /build/buildd/glib2.0-2.19.4/glib/gthread.c line 635
  • #6 start_thread
    from /lib/libpthread.so.0
  • #7 clone
    from /lib/libc.so.6
  • #8 ??
(gdb) 


This seems like bug 555276, but this is fixed on trunk...

Also interesting: I see this on the console output, just before the crash:

camel_db_select:
SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'EDE/SCI' WHERE uid = '`k-' 

===========
DB SQL operation [SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'EDE/SCI' WHERE uid = '`k-'] started
DB Operation ended. Time Taken : 0.000103
###########
CamelException.set(0x7fff203418b0, 2, 'no uid [`k-] exists')

camel_db_select:
SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM camel_db_select:
SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'EDE/SCI' WHERE uid = '`k-' 

===========
DB SQL operation [SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'EDE/SCI' WHERE uid = '`k-'] started
DB Operation ended. Time Taken : 0.000103
###########

The above is repeated some times.
Comment 1 C de-Avillez 2009-01-13 23:30:26 UTC
another crash:

  • #0 vee_get_message
    at ../../../evolution-data-server/camel/camel-vee-folder.c line 647
  • #1 camel_folder_get_message
    at ../../../evolution-data-server/camel/camel-folder.c line 1148
  • #2 get_message_exec
    at ../../../evolution/mail/mail-ops.c line 1824
  • #3 mail_msg_proxy
    at ../../../evolution/mail/mail-mt.c line 520
  • #4 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.19.4/glib/gthreadpool.c line 265
  • #5 g_thread_create_proxy
    at /build/buildd/glib2.0-2.19.4/glib/gthread.c line 635
  • #6 start_thread
    from /lib/libpthread.so.0
  • #7 clone
    from /lib/libc.so.6
  • #8 ??
(gdb) set print pretty
(gdb) set print array
(gdb) print *uid
$1 = 0 '\0'


and this is the end of the console output:

===========
DB SQL operation [SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'Memberships/FLOSS/Ubuntu-packages' WHERE uid = 'es/DynDNS'] started
DB Operation ended. Time Taken : 0.000102
###########
CamelException.set(0x7fff9e8cd5b0, 2, 'no uid [es/DynDNS] exists')

camel_db_select:
SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'Memberships/FLOSS/Ubuntu-packages' WHERE uid = 'es/DynDNS' 

===========
DB SQL operation [SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'Memberships/FLOSS/Ubuntu-packages' WHERE uid = 'es/DynDNS'] started
DB Operation ended. Time Taken : 0.000097
###########

(evolution:16053): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed

(evolution:16053): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed

It is worth noting I *do* have an IMAP folder called "Utilities/DynDNS", so this indeed seems like a memory overrun.
Comment 2 Srinivasa Ragavan 2009-01-19 04:48:05 UTC
was it reproducible? Did you try a run on valgrind --tool=memcheck ? That would be lot useful
Comment 3 C de-Avillez 2009-01-19 04:57:54 UTC
Srini, I did not yet run Valgrind on it. But -- as I sort of expected --, after I removed the "Unread" search folder I did not experience the SIGSEGV again.

I will add the search folder again, and start Evo under Valgrind (and go to bed). Hopelly this will provide us some insight.
Comment 4 C de-Avillez 2009-01-19 16:28:13 UTC
Created attachment 126772 [details]
valgrind log

Here you go. I see some unresolved symbols -- probably an update to my system caused a debug library to be dropped. I will find out which libraries got updated, and reload the corresponding DBG.

Meanwhile, I hope this can help. There seem to be quite some memory losses.
Comment 5 Srinivasa Ragavan 2009-01-20 09:12:52 UTC
It seems to be a uid is over-freed. Hggdh, I know you build/frequently daily from svn. Since when are you seeing this on trunk?
Comment 6 Akhil Laddha 2009-01-21 03:44:51 UTC
*** Bug 568448 has been marked as a duplicate of this bug. ***
Comment 7 Akhil Laddha 2009-01-21 03:45:02 UTC
*** Bug 568452 has been marked as a duplicate of this bug. ***
Comment 8 Akhil Laddha 2009-01-22 03:38:49 UTC
*** Bug 568549 has been marked as a duplicate of this bug. ***
Comment 9 C de-Avillez 2009-01-22 04:01:31 UTC
srag, since about 2 weeks ago.
Comment 10 Srinivasa Ragavan 2009-01-22 04:20:51 UTC
Never mind, I found a way to reproduce it. I will fix it pro'lly today.
Comment 11 Srinivasa Ragavan 2009-01-22 04:40:21 UTC
Created attachment 126965 [details] [review]
Don't strdup when it should be just str-reffed

Your patch here  :-)
Comment 12 C de-Avillez 2009-01-22 05:37:47 UTC
OK. I am now running with the patch on, and back with an "unread" search folder, threaded by subject.

Should be a few days to be sure.
Comment 13 C de-Avillez 2009-01-22 20:06:47 UTC
I did not get the *same* SEGV...

I was on my unread search folder, Ctrl-K each message (thus forcing updates).

I suddenly got a SEGV on IA__g_str_hash; restarted Evo, and got immediately hit by another SEGV, now on IA__g_slice_alloc. Again restarted Evolution, everything fine.

I opened bug 568750 on that.
Comment 14 C de-Avillez 2009-01-23 02:02:25 UTC
Well... indeed, now, as soon as I Ctrl-K on an email in the unread search folder, I get the SEGV above.
Comment 15 C de-Avillez 2009-01-23 03:05:34 UTC
Created attachment 127056 [details]
valgrind log

It seems to be a timing issue. I was able to get a SEGV just by marking read an email when in the unread search folder. So I ran Evo under Valgrind to see what happened.

So what happened... no SEGV.

I am attaching the valgrind log, anyway/
Comment 16 C de-Avillez 2009-01-23 20:19:46 UTC
Ends up this is a duplicate of bug 562449, and I am marking as such. The patches here do not apply -- I am running trunk, and the patches were for stable 2.24.3.

*** This bug has been marked as a duplicate of 562449 ***
Comment 17 Akhil Laddha 2009-01-28 04:57:03 UTC
*** Bug 569421 has been marked as a duplicate of this bug. ***
Comment 18 Srinivasa Ragavan 2009-01-29 15:25:04 UTC
Infact this is a separate bug. Im keeping it open.
Comment 19 Srinivasa Ragavan 2009-01-29 15:29:17 UTC
Commited to stable/trunk. But I will leave the bug open, so close when you don't see the crash again. I never happend to get it really.
Comment 20 Brian J. Murrell 2009-10-23 20:19:11 UTC
I'm still seeing this on 2.26.1:

Thread 1 (process 20321)

  • #0 __kernel_vsyscall
  • #1 raise
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c line 42
  • #2 nsProfileLock::FatalSignalHandler
    at nsProfileLock.cpp line 212
  • #3 <signal handler called>
  • #4 vee_get_message
    at camel-vee-folder.c line 657
  • #5 camel_folder_get_message
    at camel-folder.c line 1148
  • #6 get_message_exec
    at mail-ops.c line 1824
  • #7 mail_msg_proxy
    at mail-mt.c line 520
  • #8 g_thread_pool_thread_proxy
    at /usr/src/glib2.0-2.20.1/glib/gthreadpool.c line 265
  • #9 g_thread_create_proxy
    at /usr/src/glib2.0-2.20.1/glib/gthread.c line 635
  • #10 start_thread
    at pthread_create.c line 297
  • #11 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130

Comment 21 Brian J. Murrell 2009-10-27 12:17:46 UTC
Milan, per bug 574940, the previous comment is a trace from this new crasher.  Any thoughts moving forward?

Perhaps this will all just become moot.  If I find some time today, perhaps I will update to Ubuntu 9.20 RC which has gnome 2..28 and see what new crop of bugs is waiting.  :-/

In any case, maybe I won't get time so how shall we pursue this crasher?
Comment 22 Milan Crha 2009-10-27 12:42:01 UTC
(In reply to comment #21)
> Any thoughts moving forward?

I was trying to reproduce it on my machine, with some similar virtual folders, but with no luck. I left it running couple hours and it didn't want to crash, neither in this particular function. I didn't try with gmane yet, maybe that's the difference.

I will appreciate if you can move to latest stable (2.28), as it's much easier to manage code changes there.
Comment 23 Milan Crha 2009-10-27 12:43:45 UTC
Maybe try a valgrind log again? I lost all the ideas how to track this down.
Comment 24 Akhil Laddha 2011-04-12 10:27:56 UTC
Can you please check again whether this issue still happens in Evolution 2.32.2 or 3.0 and update this report by adding a comment and changing the "Version"
field? Thanks a lot.
Comment 25 Akhil Laddha 2011-06-02 05:26:57 UTC
Please feel free to reopen the bug if the problem still occurs with a newer
version of GNOME 3.0.1 or later, thanks.