Closed
Bug 720168
Opened 12 years ago
Closed 12 years ago
Crash in nsHttpChannel::CallOnStartRequest @ objc_msgSend | nsOSHelperAppService::GetMIMEInfoFromOS
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla12
People
(Reporter: scoobidiver, Assigned: smichaud)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
2.01 KB,
patch
|
BenWa
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•12 years ago
|
||
Looks like I was too aggressive in optimizing my patch for bug 675356. Patch coming up shortly.
Assignee: nobody → smichaud
Blocks: 675356
Assignee | ||
Comment 2•12 years ago
|
||
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 3•12 years ago
|
||
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+
Assignee | ||
Comment 4•12 years ago
|
||
> 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().
Assignee | ||
Comment 5•12 years ago
|
||
Comment on attachment 590839 [details] [diff] [review] Fix Landed on mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/8ec6ce57086f
Assignee | ||
Updated•12 years ago
|
Whiteboard: [inbound]
Comment 6•12 years ago
|
||
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.
Description
•