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.
MimeMultipart_parse_line is still current 3.0b4pre #1 topcrash . But I don't see multiple eof calls in all of them. Can you check if this bug matches up?  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  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
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.
v.fixed per Bug 482879 comment 41