GNOME Bugzilla – Bug 329237
Evolution crashes when opening a certain message
Last modified: 2013-09-13 00:50:57 UTC
Distribution: Mandriva Linux release 2006.0 (Official) for i586 Package: Evolution Priority: Normal Version: GNOME2.13.90 unspecified Gnome-Distributor: JHBuild Synopsis: Evolution crashes when opening a certain message Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.13.90) Description: Description of the crash: Evolution crashes when opening a certain message . The message is on an IMAP account, has two attachements: one text/plain and one text/html, and was sent with Thunderbird/Win. It contains no encription or digital signatures. Steps to reproduce the crash: 1. Select a the guilty message Expected Results: Preview the message How often does this happen? Always Debugging Information: Backtrace was generated from '/opt/gnome2/bin/evolution-2.6' Using host libthread_db library "/lib/tls/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1231431456 (LWP 21052)] [New Thread -1328014416 (LWP 21337)] [New Thread -1298375760 (LWP 21071)] [New Thread -1289983056 (LWP 21067)] [New Thread -1280857168 (LWP 21061)] [New Thread -1272460368 (LWP 21058)] [New Thread -1264034896 (LWP 21055)] [New Thread -1255642192 (LWP 21054)] [New Thread -1247216720 (LWP 21053)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 65751
Thread 1 (Thread -1231431456 (LWP 21052))
138578964, 3074076640, 3220879116, 3066695520, 3220879116, 3066695520, 3074846164, 3220879156, 3220879108, 138574216, 0, 139938624, 33207976, 3066611038, 0, 139973880, 139644640, 0, 409, 3291, 1, 139938272, 134630888, 139973336, 1090172648, 3066694608, 138574216}}, sa_flags = 138574216, sa_restorer = 0xbffab6e8} pid = ------- Bug created by bug-buddy at 2006-01-30 17:05 -------
Something wrong in the attachment bar.
critical warning crash.
(In reply to comment #2) > critical warning crash. > Please note that I have GNOME set up to not crash on criticals when this happens.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. Strange stacktrace in bug 312989, but the relevant thread is identical. This is a duplicate of bug 312989. Going to reopen that one. Identical stacktrace, same description, same suspect (attachment bar). *** This bug has been marked as a duplicate of 312989 ***
No. It is no way a duplicate. bug 312989 is about a memory corruption in the attachment bar code. But the dupe bug 329237 is about some stupid g_assert there. Which needs more attention. This bug is in the code path, that adds a atachment button at the end of the message and no way related to the attachment bar code. Closing this as fixed and reopening the duplicate.
Victor, Are you able to see the bug consistently? Im using HEAD and Im not able to see it. As I see the code wrt trace
+ Trace 66225
The code em-format-html-display.c: info = (struct _attach_puri *)em_format_find_puri((EMFormat *)efh, pobject->classid); g_assert(info != NULL); g_assert(info->forward == NULL); // CRASHES HERE for above trace. if (efhd->priv->attachment_bar) { And this info->forward is no where initialized to NULL, only after this assert they create the widget. Just I wanted to know, how did this crash happened. Is it continous? I can fix this by initializing the variable, but just checking ... :)
Srini, this needs to be fixed. :)
partha: are you facing this? Im not able to see this at all.
> Victor, Are you able to see the bug consistently? Im using HEAD and Im not able > to see it. It was easily reproducible, but not anymore on HEAD, so I'd say this is fixed. Feel free to close if you agree.
THanks. Closing as obsolete. I dont see this on HEAD anymore.
Still seeing this here. I'll attach a message to reproduce it with. I'm running FC7 development at the moment so it *could* be some patch there that is causing it to rear it's ugly head again.
*** This bug has been marked as a duplicate of 394082 ***