Investigate crash [@ MimeMultipart_parse_line] possibly caused by MimeMultipartRelated_parse_eof getting called twice on a single instance.

VERIFIED FIXED in Thunderbird 3.0b4

Status

MailNews Core
MIME
--
critical
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: Bienvenu, Unassigned)

Tracking

({crash})

Trunk
Thunderbird 3.0b4
x86
Windows Vista
crash
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

9 years ago
spun-off from bug 482879 - in particular, this comment from asuth:

he best explanation I can come up with for what is happening here is that
MimeMultipartRelated_parse_eof is getting called twice on a single instance.

My patch at http://hg.mozilla.org/comm-central/rev/f0bdc29e9c1c changed the
behavior so that if a second pass through happens, we will not fix-up
body->parent or body->options to be equal to obj and obj->options,
respectively.
(The logic replaces relobj->headobj with the newly created node; on the second
pass through, there relobj->headobj is no longer there to be replaced!)

This would likely reslt in both the crash observed in this crasher, as well as
this one in MimeInlineTextHTML_parse_eof that we have 5 of in 3.0b3pre:
http://crash-stats.mozilla.com/report/index/03c18437-350c-4d31-94ab-d644d2090510
and this slightly different crash in the same place:
http://crash-stats.mozilla.com/report/index/615903d3-9330-4b10-ae4e-129b02090510

In all cases it looks like the situation is caused by the multipart/related
being embedded inside a multipart itself.  Presumably mimemult.cpp has some
scenario in which it does the call multiple times.  I was unable to quickly
cause gloda's test_mime_emitter.js to cause the problem but the stack traces
aren't giving me much to go on and I haven't written a fuzzer.

In bug 482879, we've papered over the crash since we can't find a reproducible case. This bug is to figure out the underlying issue.
(Reporter)

Comment 1

9 years ago
marking this as blocking b4, until we can show that it doesn't.
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b4

Comment 2

9 years ago
MimeMultipart_parse_line is still current 3.0b4pre #1 topcrash [1]. But I don't see multiple eof calls in all of them.[2] Can you check if this bug matches up?

[1] 3.0b4pre topcrash list
http://crash-stats.mozilla.com/query/query?product=Thunderbird&version=Thunderbird%3A3.0b4pre&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=&do_query=1

[2] http://crash-stats.mozilla.com/report/list?product=Thunderbird&version=Thunderbird%3A3.0b4pre&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=MimeMultipart_parse_line
Summary: Investigate crash possibly caused by MimeMultipartRelated_parse_eof getting called twice on a single instance. → Investigate crash [@ MimeMultipart_parse_line] possibly caused by MimeMultipartRelated_parse_eof getting called twice on a single instance.
Whiteboard: topcrash?
It seems like the crashes are related to this bug, yes.  Is there a way to tell if the crashes are all coming from just two persistent but unlucky machines?  I saw two different processor configurations in the bug, so am presuming at least two are involved...
(Reporter)

Comment 4

9 years ago
fix for bug 482879 seems to have taken this crash out of the top-crash list - so I'm marking this fixed for now. If it re-appears, we can re-open this bug.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 5

9 years ago
v.fixed per Bug 482879 comment 41
Status: RESOLVED → VERIFIED

Updated

8 years ago
Severity: normal → critical
Keywords: crash
Whiteboard: topcrash?
(Assignee)

Updated

7 years ago
Crash Signature: [@ MimeMultipart_parse_line]
You need to log in before you can comment on or make changes to this bug.