Closed Bug 720168 Opened 12 years ago Closed 12 years ago

Crash in nsHttpChannel::CallOnStartRequest @ objc_msgSend | nsOSHelperAppService::GetMIMEInfoFromOS

Categories

(Core :: Networking: HTTP, defect)

12 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: scoobidiver, Assigned: smichaud)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

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
Looks like I was too aggressive in optimizing my patch for bug 675356.  Patch coming up shortly.
Assignee: nobody → smichaud
Blocks: 675356
Attached patch FixSplinter Review
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 :-(
Attachment #590839 - Flags: review?(bgirard)
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?
Attachment #590839 - Flags: review?(bgirard) → review+
> 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().
Whiteboard: [inbound]
https://hg.mozilla.org/mozilla-central/rev/8ec6ce57086f
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla12
You need to log in before you can comment on or make changes to this bug.