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 680123 - Freeze on message/disposition-notification email parsing
Freeze on message/disposition-notification email parsing
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.6.x (obsolete)
Other Linux
: High critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[formatter]
Depends on:
Blocks:
 
 
Reported: 2012-07-17 18:11 UTC by Fabio
Modified: 2013-09-13 01:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
under gdb snipped (91.62 KB, text/plain)
2012-07-17 22:25 UTC, Fabio
  Details
under valgrind (320.99 KB, text/x-log)
2012-07-17 22:26 UTC, Fabio
  Details
Fix (1.96 KB, patch)
2012-07-18 10:16 UTC, Dan Vrátil
committed Details | Review

Description Fabio 2012-07-17 18:11:20 UTC
Hallo
This bug is reproducible only with some e-mail, I've tried reinstalling and purging but not to solve.
Seems that it has problem in parsing message, and if you need more just let me know.
The attached output are very large (15-30 MB)
Thanks
Fabio
Comment 2 Fabio 2012-07-17 19:59:38 UTC
I can reproduce this bug everytime but only with those two mails sended from two different and trusted sources (one is just a receive of reading a sended mail).

From gdb log:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb5537700 (LWP 2478)]
_IO_vfprintf_internal (s=0x7fffb4d38660, format=0x7fffc7df3781 "%s/*", ap=0x7fffb4d387c8) at vfprintf.c:1329
1329	vfprintf.c: No such file or directory.
Comment 3 André Klapper 2012-07-17 20:27:27 UTC
Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 4 Fabio 2012-07-17 22:25:42 UTC
Created attachment 219073 [details]
under gdb snipped
Comment 5 Fabio 2012-07-17 22:26:34 UTC
Created attachment 219074 [details]
under valgrind
Comment 6 Dan Vrátil 2012-07-18 08:30:35 UTC
Could you please provide the actual message that causes the crash? You can remove any sensitive information and content, it is only necessary to preserve structure of the message.
Comment 7 Fabio 2012-07-18 08:49:03 UTC
I forward you the message, is the.
FW:Letto:R:SOSTITUZIONE.......
I can remeber that the first things I was trying to do was to delete that message, but evolution freezed
Comment 8 Dan Vrátil 2012-07-18 10:16:02 UTC
Created attachment 219084 [details] [review]
Fix

For reference, the structure of the email from Fabio was
multipart/mixed
  multipart/alternative
    text/plain
    text/html
  message/disposition-notification

The endless-recursion was caused by the last part.

This patch adds support for message/disposition-notification and message/feedback-report (reported to me by yaneti on IRC the other day) to message-rfc822 parser and removes support for message/* (fallback for unknown subtype of message mime type).

The message/* has been removed, because when the subtype is unkown to us, the fallback message/* type is used, but the EMailParserMessageRFC822 causes EMailParser to end up in endless recursion because it keeps trying to parse the content of message/* as message/* (makes sense if you understand the parser a bit :-). 

Removing the message/* fixes the recursion problem. Unknown message/* will now always be parsed only as an attachment, but because I added message/* to plain-text formatter, it will be always displayed as plain text (e.g. the source of the message will be displayed).

Testing: tried with all my testing mailbox and all behaves as expected, including emails with message/disposition-notification and message/feedback-report parts.
Comment 9 Milan Crha 2012-07-18 12:25:28 UTC
Untested, but your explanation makes sense. Please commit.
Comment 11 Fabio 2012-08-09 08:20:15 UTC
Verification done.
Thanks
Fabio