548719 - crash [@ CFRelease | nsOSHelperAppService::GetMIMEInfoFromOS(nsACString_internal const&, nsACString_internal const&, int*) ]

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[Michael A. Pasek]

crash [@ CFRelease | nsOSHelperAppService::GetMIMEInfoFromOS(nsACString_internal const&, nsACString_internal const&, int*) ]

#33 in 3.0.1 Top Mac 100 crashes (1 week), not in top 100 overall
  (total 38, all Mac, Feb02-Feb25)

3.0.1 - 22 occurrences, 2 MacOS 10.5.8 (9L30), 20 MacOS 10.6.2 (10C540)
3.0.2 - 5 occurrences, MacOS 10.6.2 (10C540)
3.1a1 - 4 occurrences, MacOS 10.6.2 (10C540)
3.1b1pre - 5 occurrences, MacOS 10.5.8 (9L30)

This appears to be a particularly nasty bug related to the display of MIME data.  In some cases, it appears to be processing an attachment (either on incoming, or in a compose window), other cases appear to be from newsfeeds.  What makes this bug nasty is that it appears that the "state" is remembered; a subsequent relaunch causes an immediate failure (as can be seen by a large uptime for the initial crash report and small uptimes for subsequent ones, with very little elapsed time on the timestamps).

One set of user comments (all obviously the same user):
  1) So this isn't working out too well :D
  2) Again!
  3) Four
  4) Five

The crashes are in code added as a result of Bug 489864 (but may be due to previously-unrecognized Apple bugs; see c#29 in Bug 489864).

bp-91d5e521-e528-44d7-9fa9-abec62100219  v3.0.1  Build20100111130305
0	CoreFoundation	CFRelease	
1	thunderbird-bin	nsOSHelperAppService::GetMIMEInfoFromOS	uriloader/exthandler/mac/nsOSHelperAppService.mm:326
2	thunderbird-bin	nsExternalHelperAppService::GetTypeFromExtension	uriloader/exthandler/nsExternalHelperAppService.cpp:2594
3	thunderbird-bin	mime_file_type	mailnews/mime/src/mimemoz2.cpp:741
4	thunderbird-bin	MimeUntypedText_parse_line	mailnews/mime/src/mimeunty.cpp:466
5	thunderbird-bin	convert_and_send_buffer	mailnews/mime/src/mimebuf.cpp:184
6	thunderbird-bin	mime_LineBuffer	mailnews/mime/src/mimebuf.cpp:272
7	thunderbird-bin	MimeObject_parse_buffer	mailnews/mime/src/mimeobj.cpp:275
8	thunderbird-bin	MimeMessage_parse_line	mailnews/mime/src/mimemsg.cpp:232
9	thunderbird-bin	convert_and_send_buffer	mailnews/mime/src/mimebuf.cpp:184
10	thunderbird-bin	mime_LineBuffer	mailnews/mime/src/mimebuf.cpp:272
11	thunderbird-bin	MimeObject_parse_buffer	mailnews/mime/src/mimeobj.cpp:275
12	thunderbird-bin	mime_display_stream_write	mailnews/mime/src/mimemoz2.cpp:949
13	thunderbird-bin	nsStreamConverter::OnDataAvailable	mailnews/mime/src/nsStreamConverter.cpp:957
14	thunderbird-bin	nsStreamListenerTee::OnDataAvailable	netwerk/base/src/nsStreamListenerTee.cpp:97
15	thunderbird-bin	nsNNTPProtocol::DisplayArticle	mailnews/news/src/nsNNTPProtocol.cpp:2490
16	thunderbird-bin	nsNNTPProtocol::ReadArticle	mailnews/news/src/nsNNTPProtocol.cpp:2541
17	thunderbird-bin	nsNNTPProtocol::ProcessProtocolState	mailnews/news/src/nsNNTPProtocol.cpp:4886
18	thunderbird-bin	nsMsgProtocol::OnDataAvailable	mailnews/base/util/nsMsgProtocol.cpp:359
19	thunderbird-bin	nsInputStreamPump::OnStateTransfer	netwerk/base/src/nsInputStreamPump.cpp:508
20	thunderbird-bin	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:398

bp-cc5bf178-a761-41d6-a219-9b7c42100225  v3.1b1pre  Build20100214060622
0	CoreFoundation	CFRelease	
1	thunderbird-bin	nsOSHelperAppService::GetMIMEInfoFromOS	uriloader/exthandler/mac/nsOSHelperAppService.mm:278
2	thunderbird-bin	nsExternalHelperAppService::GetFromTypeAndExtension	uriloader/exthandler/nsExternalHelperAppService.cpp:2463
3	thunderbird-bin	nsExternalHelperAppService::GetPrimaryExtension	uriloader/exthandler/nsExternalHelperAppService.cpp:2631
4	thunderbird-bin	ValidateRealName	mailnews/mime/src/mimemoz2.cpp:272
5	thunderbird-bin	GenerateAttachmentData	mailnews/mime/src/mimemoz2.cpp:473
6	thunderbird-bin	BuildAttachmentList	mailnews/mime/src/mimemoz2.cpp:525
7	thunderbird-bin	mime_display_stream_complete	mailnews/mime/src/mimemoz2.cpp:975
8	thunderbird-bin	nsStreamConverter::OnStopRequest	mailnews/mime/src/nsStreamConverter.cpp:1098
9	thunderbird-bin	nsMsgProtocol::OnStopRequest	mailnews/base/util/nsMsgProtocol.cpp:401
10	thunderbird-bin	nsMailboxProtocol::OnStopRequest	mailnews/local/src/nsMailboxProtocol.cpp:380
11	thunderbird-bin	nsInputStreamPump::OnStateStop	netwerk/base/src/nsInputStreamPump.cpp:576
12	thunderbird-bin	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:401
13	libxpcom_core.dylib	nsInputStreamReadyEvent::Run	xpcom/io/nsStreamUtils.cpp:112
14	libxpcom_core.dylib	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:527
15	libxpcom_core.dylib	NS_ProcessPendingEvents_P	 nsThreadUtils.cpp:200
16	thunderbird-bin	nsBaseAppShell::NativeEventCallback	widget/src/xpwidgets/nsBaseAppShell.cpp:121
17	thunderbird-bin	nsAppShell::ProcessGeckoEvents	widget/src/cocoa/nsAppShell.mm:494
18	CoreFoundation	CFRunLoopRunSpecific	
19	HIToolbox	RunCurrentEventLoopInMode	
20	HIToolbox	ReceiveNextEventCommon

Comment 1

[Zandr Milewski [:zandr]]

So, those crash comments were from yours truly.

This is the second crash reported in Bug 547100, which got closed as a dupe of a another bug (which only duped the first crash)

Seeing it again, and what may have triggered it this time was using Squeeze on my Profile. (Hey, seemed like a good idea at the time)

Comment 2

[Michael A. Pasek]

(In reply to comment #1)
> This is the second crash reported in Bug 547100, which got closed as a dupe of
> a another bug (which only duped the first crash)
Even with my limited knowledge, it's obvious that these crashes won't get fixed by 1cdd680a41f6 (applied to correct 537551)  -- at least, not the NNTP ones.

> Seeing it again, and what may have triggered it this time was using Squeeze on
> my Profile. (Hey, seemed like a good idea at the time)
Squeeze ?

Comment 3

[Zandr Milewski [:zandr]]

(In reply to comment #2)

> Even with my limited knowledge, it's obvious that these crashes won't get fixed
> by 1cdd680a41f6 (applied to correct 537551)  -- at least, not the NNTP ones.

Just two IMAP accounts here, not trying to use NNTP.

> Squeeze ?

Squeeze: http://www.latenitesoft.com/squeeze/

Leverages the compression hooks in the filesystem on 10.6.

Possibly coincidence, possibly the compression is triggering an issue within Lanikai.

Comment 4

[Zandr Milewski [:zandr]]

Not related to Squeeze, I don't think. Ran afscexpand on ~/Library/Thunderbird, and it still explodes.

So, uhh, how far back in time do I need to go to get to a working Thunderbird?

Comment 5

[Michael A. Pasek]

(In reply to comment #4)
> So, uhh, how far back in time do I need to go to get to a working Thunderbird?

I was under the impression -- from comment #0 in 547100 -- that going back to 3.0.1 "fixed" the problem, and it stayed "fixed" after going back to 3.1a1 again (although your comment #2 indicates you were getting frequent crashes after that).  To be honest, I don't know what broke -- or when.

I'd suggest continuing to file crash reports, with comments to indicate what you were doing (e.g., any particular mail you might have been looking at, etc.).  If the crashes were related to a particular piece of mail (or, as it appears for some cases, from a particular News article), locating that email and/or news article and attaching it here may prove useful.

Comment 6

[Wayne Mery (:wsmwk)]

zandr, are all these crashes you? 
 https://crash-stats.mozilla.com/report/list?product=Thunderbird&build_id=&query_search=signature&query_type=exact&query=CFRelease%20|%20nsOSHelperAppService%3A%3AGetMIMEInfoFromOS%28nsACString_internal%20const%26%2C%20nsACString_internal%20const%26%2C%20int*%29&date=&range_value=4&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=CFRelease%20|%20nsOSHelperAppService%3A%3AGetMIMEInfoFromOS%28nsACString_internal%20const%26%2C%20nsACString_internal%20const%26%2C%20int*%29&missing_sig=&page=1

This crash sig doesn't appear before 3.0.1. But that might be a false indicator, because IT/socorro have been massaging what frames get presented as signatures.

Comment 7

[Michael A. Pasek]

I don't think they're all him, given comment #3:
> Just two IMAP accounts here, not trying to use NNTP.

Comment 8

[Zandr Milewski [:zandr]]

No, I'm only 10.6.2/x86, and I'm not using NNTP. I include my email in all the crashes (not sure if that's accessible) and I'll start signing the comments. :D

3.0.2 seems OK, at least for now.

Since it was some background task that was causing the crash, I don't know how to exercise it.

Comment 9

[Zandr Milewski [:zandr]]

OK, so this crash has now rendered Lanikai unusable again.

Back to 3.0.x for a while.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

There are only three of these on Thunderbird in the last week (all in
3.1b1):

http://crash-stats.mozilla.com/query/query?product=Thunderbird&version=ALL%3AALL&platform=mac&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=CFRelease+|+nsOSHelperAppService%3A%3AGetMIMEInfoFromOS%28nsACString_internal+const%26%2C+nsACString_internal+const%26%2C+int*%29&build_id=&process_type=all&do_query=1

There are more (66) in Firefox ...but not enough to get into the
topcrasher list:

http://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&platform=mac&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=CFRelease+|+nsOSHelperAppService%3A%3AGetMIMEInfoFromOS%28nsACString_internal+const%26%2C+nsACString_internal+const%26%2C+int*%29&build_id=&process_type=all&do_query=1

The crash stacks all consistently show a crash at the same line -- for
example:

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/cd857b3b0e33/uriloader/exthandler/mac/nsOSHelperAppService.mm#l278

But it's very difficult to figure out how this crash is even possible.
My best guess is that, if LSCopyApplicationForMIMEType() makes an
error return, it can set appURL to the wrong value (though one which
is still a valid CoreFoundation object).  Then CFRelease(appURL)
succeeds (or at least doesn't crash), but releasing it somehow
triggers a crash at the call to CFRelease(CFType).  Or maybe the crash
actually happens at the call to CFRelease(appURL), but the line number
is somehow misreported.

It'd be nice to have a way to reproduce this, so we could test my
theory.

Comment 11

[Zandr Milewski [:zandr]]

(In reply to comment #10)
> There are only three of these on Thunderbird in the last week (all in
> 3.1b1):

I've had work to do, so I've gone back to 3.0.x. Updating 3.1b2pre now, so I should have more crashes for you soon. My experience is that I'll end up "stuck", where 3.1b will crash on restart, so if you can give me an instrumented or patched build, I should be able to test that soon.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

What I need are reliable steps-to-reproduce so *I* can reproduce the
crashes.

No need for an instrumented build -- we can already see where the
crashes are happening.

Or I could write a patch to test my theory from comment #9, do a test
build from that, and ask you to test that build.  But let's wait to
see if you can still reproduce this bug's crash in current nightlies.

Comment 13

[Zandr Milewski [:zandr]]

STR: Launch Lanikai :D

Latest nightly now crashes immediately after launch. Unless you can tell me how to figure out what it's doing, I think a test build is going to be the way to go.

I'm obviously not send you my whole profile/mail spool, but if we can identify a malformed message, that's a possiblity.

http://crash-stats.mozilla.com/report/index/f6da81ee-2745-4448-be0d-394eb2100403

Comment 14

[Steven Michaud [:smichaud] (Retired)]

I'll do a test build.

But it may not be ready for a few hours -- I'm about to do my laundry :-)

Comment 15

[Wayne Mery (:wsmwk)]

it's probably reading a message body for gloda indexing. something in a gloda debug log might tell you which message is being indexed. https://wiki.mozilla.org/Thunderbird:Debugging_Gloda  

Also, you can exclude specific folders from indexing using http://mesquilla.com/extensions/glodaquilla/

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Here's a test build.  Zandr, let us know your results.  I added some
logging that might help us figure out what's going on.  Look for it in
the console.

http://people.mozilla.com/~stmichaud/bmo/thunderbird-3.1b2pre.en-US.mac.bugzilla548719-smichaud.dmg

I don't know how to do Thunderbird tryserver builds ... or even if
that's possible.  So I built my own and uploaded it to my
people.mozilla.com account.

I couldn't find a comm-1.9.2 repository anywhere at
http://hg.mozilla.org/, so I had to hack my own.  I did this by
cloning a comm-central repo and editing its client.py to change
DEFAULT_MOZILLA_REPO from 'http://hg.mozilla.org/mozilla-central/' to
'http://hg.mozilla.org/releases/mozilla-1.9.2/'.  Then I ran 'python
client.py checkout'.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible fix and debugging patch

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible fix and debugging patch, rev1

I've uploaded a new build to the same URL (overwriting the old one):
http://people.mozilla.com/~stmichaud/bmo/thunderbird-3.1b2pre.en-US.mac.bugzilla548719-smichaud.dmg

Comment 19

[Zandr Milewski [:zandr]]

Predictably, the offending message appears to have been Russian spam. :)

I turned on the gloda logging that :wsmwk suggested, and the last message logged before the crash was of the form:

2010-04-03 13:07:05 gloda.index_msg DEBUG *** Indexing message: 4977 : =?koi8-r?B?8dDPztPLycUgxMXSxdfY0SDCz87Twco=?= 

So, I grepped for that subject line in my Maildir on the server, and have added that file as an attachment.

I'm now running the latest test/debug build with the logging active, and will let that stew overnight to see if it explodes, but it's already lived much longer than the last nightly.

PS: I know that Tbird try-server builds are possible, I've seen dmose do it. ;)

Comment 20

[Zandr Milewski [:zandr]]

Attachment: Maildir file that causes the crash

I'm presuming this caused the crash. It's the one file/message that contains the koi-8 encoded subject line that was in the last gloda logging message before the crash.

Comment 21

[Zandr Milewski [:zandr]]

Attachment: Crash report from Apple Crash Reporter

Comment 22

[Zandr Milewski [:zandr]]

I spoke too soon, the patch/debug version also failed on the same message. Though, annoyingly, it triggered the Apple crash reporter, not ours. Crash report attached above.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

Was there any logging output from my patch just before the crash?

Comment 24

[Zandr Milewski [:zandr]]

Not that I could see. Last two lines of console output are:

2010-04-03 23:38:12	gloda.index_msg	DEBUG	>>>  _indexMessage
2010-04-03 23:38:12	gloda.index_msg	DEBUG	*** Indexing message: 4977 : =?koi8-r?B?8dDPztPLycUgxMXSxdfY0SDCz87Twco=?=

(Looks exactly like before)

Do I need to turn on any additional prefs beyond the two in the wiki page :wsmwk mentioned?

Comment 25

[Zandr Milewski [:zandr]]

On subsequent runs the last line is actually:

Trace/BPT trap

Comment 26

[Wayne Mery (:wsmwk)]

not surprisingly, testcase doesn't crash for me on windows

Comment 27

[Steven Michaud [:smichaud] (Retired)]

> Was there any logging output from my patch just before the crash?

> Not that I could see.
>
> 2010-04-03 23:38:12  gloda.index_msg    DEBUG    >>>  _indexMessage
> 2010-04-03 23:38:12  gloda.index_msg    DEBUG    *** Indexing message: 4977 :
>                      =?koi8-r?B?8dDPztPLycUgxMXSxdfY0SDCz87Twco=?=

I'm looking for output that contains strings from any of the NSLog
statements in my patch.  An easy test would be to search your log
output for "nsOSHelperAppService::GetMIMEInfoFromOS()".

Comment 28

[Steven Michaud [:smichaud] (Retired)]

> Do I need to turn on any additional prefs beyond the two in the wiki
> page :wsmwk mentioned?

To see the log output from my patch?  No.  (Presuming you haven't
somehow redirected the gloda log output to a file.)  Use the Console
app (Applications : Utilities : Console) to see it.

Comment 29

[Steven Michaud [:smichaud] (Retired)]

Nevermind.  I crash my test build (on OS X 10.6.3) just opening your
message from comment #20 (the same crash as you reported in comment
#21).  My patch doesn't log anything to the console (so my theory from
comment #10 is wrong).

However I can now reproduce the crash!  So I'll keep playing with your
testcase (probably mostly tomorrow).

Comment 30

[Steven Michaud [:smichaud] (Retired)]

Crash with today's Lanikai nightly:
bp-9b3e6d90-fcaf-4cdb-8d2e-d2d172100404

I tried opening the message from comment #10 using File : Open Saved
Message.

By the way, what's Thunderbird's equivalent of "about:crashes".  I had
to find my crash id in ~/Library/Thunderbird/Crash Reports/submitted.

Comment 31

[Mark Banner (:standard8)]

(In reply to comment #30)
> By the way, what's Thunderbird's equivalent of "about:crashes".  I had
> to find my crash id in ~/Library/Thunderbird/Crash Reports/submitted.

Install the ViewAbout extension or set your start page to about:crashes.

Comment 32

[Benoit SALLES]

At Wayne Mery's demand, I save the "corrupted" file. I send you it in attachment (courriel-Ursula Melton).

In my user comments, I don't write all the story.
When I received the message, Lanikai crashed first. I didn't send the
report because I though this crash was due to too many opened
applications. I restarted Lanikai and resumed the reception. I deleted
the reported spams and scanned messages to detect the reported spam.
When I clicked to report spam for this message, Lanikai crashed again. I
restarted and saw the message as 'spam-reported' but unread. When I
clicked to change into read status message, Lanikai crashed again. I
again restarted and saw the message as 'unread'.
Furious, I clicked in the menu Outils > Supprimer les indésirables
(sorry, I use the french version of Lanikai). But when Lanikai did it,
it crashed again. So, I sent you the crash report.

At the same time, I tried to access the message in my iPhone but the
Mail application crashed too.

After that, I used Thunderbird 3.0.3 during 3 days and updated to 3.0.4.
When I returned to Lanikai, the message didn't crash the application.
But I remarked the spam message is dated as of 03-25-2010 23:54 but not
the 03-26-2010 00:06 as it should.

Hope this will help.

Comment 33

[Benoit SALLES]

Attachment: the "corrupted" spam

Comment 34

[Steven Michaud [:smichaud] (Retired)]

> the "corrupted" spam

I don't crash opening this message.

Comment 35

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix (rev2)

I've figured this bug out, and have a fix for it.

It isn't exactly an Apple bug.  But at the very least
CFStringCreateWithCString() indulges in undocumented behavior -- it
can return NULL without having run out of memory.  So under some
circumstances we need to check its return value.  (Up til now we've
assumed it will always succeed).

The crash with Zandr's testcase from comment #20 happens when
nsOSHelperAppService::GetMIMEInfoFromOS() is called with aMIMEType set
to "\xFF\xFF~".  When CFStringCreateWithCString() is called with this
as its 'cStr' parameter it returns NULL.  But our code assumes that
CFStringCreateWithCString() will never do this, and so tries to call
CFRelease() on a NULL pointer -- which triggers the crash.

(Notice the following at the very bottom of Zandr's testcase:

------=_NextPart_000_0006_01CABA8F.35E266C0
Content-Type: <FF><FF>~;
        name=""
Content-Transfer-Encoding: base64
Content-ID: <6ffec1fa$0c819832$6c822ecf>

This is what triggers the crash.)

The fix is very simple -- do a NULL check on what
CFStringCreateWithCString() returns.

There are lots of places in the tree where CFStringCreateWithCString()
is used and I haven't added NULL checks.  Most of these probably don't
need them.  But nsOSHelperAppService::GetMIMEInfoFromOS() is unusual
in that aMIMEType and aFileExt can come directly from an "external"
source.  So we shouldn't feed either to CFStringCreateWithCString()
without checking for a NULL return.

While writing this patch I noticed we've been leaking CFExt.  My patch
also fixes that problem.

Here's a build made with my new (rev2) patch:
http://people.mozilla.com/~stmichaud/bmo/thunderbird-3.1b2pre.en-US.mac.bugzilla548719-smichaud-rev2.dmg

Zandr, please test this and let us know your results.

Comment 36

[Steven Michaud [:smichaud] (Retired)]

Attachment: Small app for testing CFString methods with weird strings

Oops.  I discovered that CFStringCreateWithBytes() has the same
problem as CFStringCreateWithCString().  So I'll need to revise my
patch.

CFStringCreateWithCharacters() doesn't have the problem.

TestCFString.mm is a small app that shows this.

Comment 37

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix rev3 (clean up)

Comment 38

[Steven Michaud [:smichaud] (Retired)]

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/ed5afed89c49

The fix should appear (I think) in tomorrow's comm-central-trunk nightly.

Comment 39

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 437155 [details] [diff] [review]
Fix rev3 (clean up)

This patch is very simple, and can't cause any harm (it just adds some
NULL checks).

It fixes a crash bug (though not a topcrasher).

Comment 40

[Jonathan Kew [:jfkthame]]

(In reply to comment #35)
> It isn't exactly an Apple bug.  But at the very least
> CFStringCreateWithCString() indulges in undocumented behavior -- it
> can return NULL without having run out of memory.  So under some
> circumstances we need to check its return value.  (Up til now we've
> assumed it will always succeed).

FTR: In defense of Apple's APIs and docs, I'd say this *is* in fact documented (and reasonable) behavior. The doc for CFStringCreateWithBytes, for example, says that it returns:

  "An immutable string, or NULL if there was a problem creating the object."

Well, if the bytes passed are 0xff, 0xff, '~', and CFStringCreateWithBytes is told that the string encoding is UTF-8, then there will indeed be "a problem creating the object", as that byte sequence is invalid in UTF-8. So by returning NULL, the function is behaving exactly as specified.

Comment 41

[Steven Michaud [:smichaud] (Retired)]

> "An immutable string, or NULL if there was a problem creating the
> object."

This doesn't really absolve Apple's docs -- "if there was a problem
creating the object" is extremely vague.

In Apple's favor, though, the docs nowhere (as far as I know)
explicitly say that "if there was a problem" means (only) running out
of memory.  So when we made that assumption, we didn't have much
evidence on which to base it.

Comment 42

[Zandr Milewski [:zandr]]

I ended up having to rebuild all the gloda indexes for an unrelated reason, but I've been running the patched build for days now with no crashes.

All good, has this landed on 1.9.2?

Comment 43

[Steven Michaud [:smichaud] (Retired)]

> has this landed on 1.9.2?

Not yet.  See comment #39, where I asked for approval to land on the 1.9.2 branch.

Comment 44

[Zandr Milewski [:zandr]]

(In reply to comment #43)
> > has this landed on 1.9.2?
> 
> Not yet.  See comment #39, where I asked for approval to land on the 1.9.2
> branch.

Sorry, missed the flag. /me waits with bated breath.

Comment 45

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 437155 [details] [diff] [review]
Fix rev3 (clean up)

a=beltzner for 1.9.2 default

Comment 46

[Steven Michaud [:smichaud] (Retired)]

Landed on the 1.9.2 branch (GECKO1924_20100413_RELBRANCH):
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/04cb7925b5b0

Comment 47

[Steven Michaud [:smichaud] (Retired)]

Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/338b3d877ef3

Comment 48

[Steven Michaud [:smichaud] (Retired)]

> a=beltzner for 1.9.2 default

I took the a=1.9.2.4+ to mean I should also land this patch on GECKO1924_20100413_RELBRANCH.  Let me know if I should back it out there.

Comment 49

[Reed Loden [:reed]]

(In reply to comment #45)
> (From update of attachment 437155 [details] [diff] [review])
> a=beltzner for 1.9.2 default

(In reply to comment #46)
> Landed on the 1.9.2 branch (GECKO1924_20100413_RELBRANCH):
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/04cb7925b5b0

Why did this land on the relbranch when beltzner only gave approval for default?

Comment 50

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 437155 [details] [diff] [review]
Fix rev3 (clean up)

Sorry - I flipped the wrong flag :( Nice catch, Reed.

Comment 51

[Steven Michaud [:smichaud] (Retired)]

My mistake.  I just looked at the a=1.9.2.4+.  I'll back the patch out on the GECKO1924_20100413_RELBRANCH.

Comment 52

[Steven Michaud [:smichaud] (Retired)]

Backed out patch on GECKO1924_20100413_RELBRANCH:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8fe06049502c

Comment 53

[Al Billings [:abillings - ex-MoCo]]

Why is this marked .4-fixed when it has been backed out of the RelBranch? Removing that and marking it as .5-fixed.

Comment 54

[Steven Michaud [:smichaud] (Retired)]

Oops, forgot to change that when I did the backout.

Comment 55

[Zandr Milewski [:zandr]]

Sad that this didn't make 3.1RC1. This crash bites me often enough that it will keep me off 3.1

Comment 56

[Mark Banner (:standard8)]

(In reply to comment #55)
> Sad that this didn't make 3.1RC1. This crash bites me often enough that it will
> keep me off 3.1

Well it will make 3.1.1 whatever happens.

Comment 57

[Mark Banner (:standard8)]

I've just landed this on the Thunderbird relbranch in mozilla-1.9.2 for Thunderbird 3.1 RC 2:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/9dcd813b2fc8

Comment 58

[Al Billings [:abillings - ex-MoCo]]

Is there a clear STR for QA to use to verify that this is fixed?

Ludovic, can you verify this for 1.9.2?

Comment 59

[Ludovic Hirlimann [:Usul]]

(In reply to comment #58)
> Is there a clear STR for QA to use to verify that this is fixed?
> 
> Ludovic, can you verify this for 1.9.2?

Will do when I figure out how to reproduce.

Comment 60

[Wayne Mery (:wsmwk)]

(In reply to comment #59)
> (In reply to comment #58)
> > Is there a clear STR for QA to use to verify that this is fixed?
> > 
> > Ludovic, can you verify this for 1.9.2?
> 
> Will do when I figure out how to reproduce.

ludo, don't comment 32 and 33 or zandr offer testcases?  if those don't work have you checked crash-stats for comments/reports with addresses for steps?

Comment 61

[Wayne Mery (:wsmwk)]

zandr, et al, can you supply other testcases?  apparently no one else can force crash with the tests submitted thus far

Comment 62

[Zandr Milewski [:zandr]]

You can't reproduce with https://bugzilla.mozilla.org/attachment.cgi?id=436902 ?

That was 100% reliable for me.

If that doesn't work, I can try to trawl through those spam buckets looking for more.