Last Comment Bug 720168 - Crash in nsHttpChannel::CallOnStartRequest @ objc_msgSend | nsOSHelperAppService::GetMIMEInfoFromOS
: Crash in nsHttpChannel::CallOnStartRequest @ objc_msgSend | nsOSHelperAppServ...
Status: RESOLVED FIXED
: crash, regression
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 12 Branch
: x86 Mac OS X
: -- critical (vote)
: mozilla12
Assigned To: Steven Michaud [:smichaud] (Retired)
:
:
Mentors:
Depends on:
Blocks: 675356
  Show dependency treegraph
 
Reported: 2012-01-21 13:56 PST by Scoobidiver (away)
Modified: 2012-01-24 04:58 PST (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix (2.01 KB, patch)
2012-01-23 13:06 PST, Steven Michaud [:smichaud] (Retired)
b56girard: review+
Details | Diff | Splinter Review

Description Scoobidiver (away) 2012-01-21 13:56:06 PST
It's a new crash signature that first appeared in 12.0a1/20120120 with 3 crashes per build.
The regression window is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58e933465c36&tochange=5c2bc94d359c

Signature 	objc_msgSend | nsOSHelperAppService::GetMIMEInfoFromOS More Reports Search
UUID	56b4ff8c-3fde-4478-a683-ecb3b2120121
Date Processed	2012-01-21 15:11:37
Uptime	15
Last Crash	27 seconds before submission
Install Age	15 seconds since version was first installed.
Install Time	2012-01-21 15:11:09
Product	Firefox
Version	12.0a1
Build ID	20120121031049
Release Channel	nightly
OS	Mac OS X
OS Version	10.7.2 11C74
Build Architecture	x86
Build Architecture Info	family 6 model 42 stepping 7
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x61297bb7
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x6740 	
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libobjc.A.dylib 	objc_msgSend 	
1 	XUL 	nsOSHelperAppService::GetMIMEInfoFromOS 	uriloader/exthandler/mac/nsOSHelperAppService.mm:279
2 	XUL 	nsExternalHelperAppService::GetFromTypeAndExtension 	uriloader/exthandler/nsExternalHelperAppService.cpp:2479
3 	XUL 	nsExternalHelperAppService::DoContent 	uriloader/exthandler/nsExternalHelperAppService.cpp:740
4 	XUL 	nsDocumentOpenInfo::DispatchContent 	uriloader/base/nsURILoader.cpp:567
5 	XUL 	nsDocumentOpenInfo::OnStartRequest 	uriloader/base/nsURILoader.cpp:294
6 	XUL 	nsHttpChannel::CallOnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:764
7 	XUL 	nsHttpChannel::ContinueProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1258
8 	XUL 	nsHttpChannel::ProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1195
9 	XUL 	nsHttpChannel::ProcessResponse 	netwerk/protocol/http/nsHttpChannel.cpp:1097
10 	XUL 	nsHttpChannel::OnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4152
11 	XUL 	nsInputStreamPump::OnStateStart 	netwerk/base/src/nsInputStreamPump.cpp:444
12 	XUL 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:399
13 	XUL 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:114
14 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
15 	XUL 	NS_ProcessPendingEvents_P 	obj-firefox/i386/xpcom/build/nsThreadUtils.cpp:195
16 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/xpwidgets/nsBaseAppShell.cpp:130
17 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/cocoa/nsAppShell.mm:441
18 	CoreFoundation 	__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 	
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=objc_msgSend%20|%20nsOSHelperAppService%3A%3AGetMIMEInfoFromOS
Comment 1 Steven Michaud [:smichaud] (Retired) 2012-01-23 09:20:24 PST
Looks like I was too aggressive in optimizing my patch for bug 675356.  Patch coming up shortly.
Comment 2 Steven Michaud [:smichaud] (Retired) 2012-01-23 13:06:10 PST
Created attachment 590839 [details] [diff] [review]
Fix

Getting an object from a "dictionary" or array doesn't automatically increase its reference count.  So deleting the dictionary/array may also delete the object.

I should have remembered that :-(
Comment 3 Benoit Girard (:BenWa) 2012-01-23 14:17:30 PST
Comment on attachment 590839 [details] [diff] [review]
Fix

r+ assuming the values in mimeTypes are properly retained. Does CFArrayAppendArray retain/copy so that the reference are still valid after the release?
Comment 4 Steven Michaud [:smichaud] (Retired) 2012-01-23 14:31:08 PST
> Does CFArrayAppendArray retain/copy so that the reference are still
> valid after the release?

Yes.  Adding any CF object to an array or dictionary increases its
reference count.  (Removing a CF object from an array/dictionary
decreases its reference count; deleting an array/dictionary decreases
the reference count of every object in the array/dictionary.)

> r+ assuming the values in mimeTypes are properly retained.

Every CF object added to mimeTypes has its reference count increased.
So those objects are guaranteed to stay alive until mimeTypes itself
is deleted -- which is the responsibility of the method that calls
GetMIMETypesHandledByApp().
Comment 5 Steven Michaud [:smichaud] (Retired) 2012-01-23 14:39:29 PST
Comment on attachment 590839 [details] [diff] [review]
Fix

Landed on mozilla-inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/8ec6ce57086f
Comment 6 Marco Bonardo [::mak] 2012-01-24 04:58:30 PST
https://hg.mozilla.org/mozilla-central/rev/8ec6ce57086f

Note You need to log in before you can comment on or make changes to this bug.