Closed Bug 496886 Opened 15 years ago Closed 15 years ago

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

Categories

(MailNews Core :: MIME, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0b4

People

(Reporter: Bienvenu, Unassigned)

Details

(Keywords: crash)

Crash Data

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.
marking this as blocking b4, until we can show that it doesn't.
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b4
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...
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
Closed: 15 years ago
Resolution: --- → FIXED
v.fixed per Bug 482879 comment 41
Status: RESOLVED → VERIFIED
Severity: normal → critical
Keywords: crash
Whiteboard: topcrash?
Crash Signature: [@ MimeMultipart_parse_line]
You need to log in before you can comment on or make changes to this bug.