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 352396 - Crashing Flipping Between Folders
Crashing Flipping Between Folders
Status: RESOLVED DUPLICATE of bug 324168
Product: evolution
Classification: Applications
Component: Mailer
2.8.x (obsolete)
Other All
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 385632 424617 433273 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-08-22 14:27 UTC by David Richards
Modified: 2008-04-02 15:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Fix - (workaround) (766 bytes, patch)
2007-02-09 18:35 UTC, Veerapuram Varadhan 		reviewed Details | Review
Patch which applies to rev 8578 (879 bytes, patch)
2008-03-20 12:42 UTC, Tobias Mueller 		none Details | Review

Description David Richards 2006-08-22 14:27:48 UTC 
Steps to reproduce:
Flipped from Mailbox to SentItems, crashed right after UI updated.

Stack trace:
Backtrace was generated from '/usr/local/bin/evolution-2.8'

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1231743312 (LWP 2091)]
[New Thread -1357788256 (LWP 2801)]
[New Thread -1315415136 (LWP 2208)]
[New Thread -1319109728 (LWP 2206)]
[New Thread -1307022432 (LWP 2177)]
[New Thread -1298629728 (LWP 2173)]
[New Thread -1257698400 (LWP 2109)]
[New Thread -1276122208 (LWP 2108)]
[New Thread -1267729504 (LWP 2107)]
[New Thread -1249305696 (LWP 2104)]
0xffffe410 in __kernel_vsyscall ()

+ Trace 70820

Thread 2 (Thread -1357788256 (LWP 2801))

  • #0 __kernel_vsyscall
  • #1 __lll_mutex_lock_wait
    from /lib/libpthread.so.0
  • #2 _L_mutex_lock_71
    from /lib/libpthread.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 segv_redirect
    at main.c line 427
  • #7 <signal handler called>
  • #8 ??
  • #9 camel_message_info_uint32
    at camel-folder-summary.c line 2985
  • #10 vee_info_uint32
    at camel-vee-summary.c line 71
  • #11 camel_message_info_uint32
    at camel-folder-summary.c line 2985
  • #12 folder_getv
    at camel-folder.c line 352
  • #13 camel_object_get
    at camel-object.c line 1598
  • #14 camel_folder_get_unread_message_count
    at camel-folder.c line 584
  • #15 update_1folder
    at mail-folder-cache.c line 367
  • #16 folder_changed
    at mail-folder-cache.c line 462
  • #17 camel_object_trigger_event
    at camel-object.c line 1504
  • #18 folder_changed_change
    at camel-vee-folder.c line 1418
  • #19 session_thread_received
    at camel-session.c line 531
  • #20 thread_dispatch
    at e-msgport.c line 987
  • #21 start_thread
    from /lib/libpthread.so.0
  • #22 clone
    from /lib/libc.so.6 


Other information:
Comment 1 David Richards 2006-08-22 14:37:07 UTC 
adding chen, feels like another threading one.
Comment 2 Kjartan Maraas 2007-01-16 16:11:51 UTC 
It also crashes deep in xlib/gtk/gdk etc. Could you get us backtraces with debug packages for those installed?
Comment 3 palfrey 2007-01-20 17:28:12 UTC 
*** Bug 385632 has been marked as a duplicate of this bug. ***
Comment 4 palfrey 2007-01-20 17:29:21 UTC 
Comment #5 of Bug 385632 has a much more detailed stack trace for this one, with debug symbols for darn near everything.
Comment 5 Jeffrey Stedfast 2007-02-08 18:52:30 UTC 
I would suspect the crash is more vfolder related (see thread 2) than X or gdk/gtk - I could, of course, be wrong ;)
Comment 6 Veerapuram Varadhan 2007-02-09 18:35:56 UTC 
Created attachment 82238 [details] [review]
Fix - (workaround)

This should possibly fixes the issue.

Jeff: Yes, CamelVeeMessageInfo* maintains a CamelMessageInfo* of the original message and it somehow gets double-unreffed in due course of time.  Due to which, it crashes.  My workaround will clone the original CamelMessageInfo* and free it when the associated CamelVeeMessageInfo* is freed.

I am open to suggestions that can lead us to a much-cleaner fix.  :-)
Comment 7 André Klapper 2007-04-12 21:17:02 UTC 
*** Bug 424617 has been marked as a duplicate of this bug. ***
Comment 8 André Klapper 2007-04-12 21:17:36 UTC 
varadhan: ping
can that workaround go in, please?
Comment 9 Srinivasa Ragavan 2007-06-01 21:51:55 UTC 
Varadhan, How about just reffing it and unreffing there?. clone would increase the memory requirement by double. Isnt it?
Comment 10 Tobias Mueller 2007-10-09 18:24:24 UTC 
Similar issues in bug 412301
Comment 11 André Klapper 2007-12-29 20:01:06 UTC 
varadhan: ping, ping, ping. (you're not working on mono, are you? ;-)
Comment 12 Tobias Mueller 2008-03-20 12:31:23 UTC 
*** Bug 433273 has been marked as a duplicate of this bug. ***
Comment 13 Tobias Mueller 2008-03-20 12:42:35 UTC 
Created attachment 107674 [details] [review]
Patch which applies to rev 8578

The Patch doesn't apply anymore (just an offset of 30 lines or so), so I'll attach an more up-to-date patch (and draw some attention to the bug ;-) ). Though I don't suggest to commit it, since it does ugly things ;-)

However, we receive still seem to hit this bug in 2.12, as in bug 523246. Hence a fix would be good ;-)
Comment 14 Milan Crha 2008-04-02 15:30:52 UTC 
Thanks for the rewrite Tobias, but the patch is no longer needed, it has been fixed with a patch from bug #324168, unfortunately it didn't touch 2.12 branch.
To explain more, the reason why it crashed in camel_message_info_uint32 was that the message info has set a summary, but the summary gone (was freed) and thus trying to access it leads to crash.

Feel free to mark this as a duplicate of the above bug.
Comment 15 Tobias Mueller 2008-04-02 15:43:26 UTC 
Thx Milan. Closing as dup of 324168 as per comment #14.


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