Closed Bug 633450 Opened 15 years ago Closed 15 years ago

Crash in nsDocument::InitCSP [@ CopyUnicodeTo ]

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: scoobidiver, Assigned: chofmann)

Details

(Keywords: crash, regression, topcrash)

Crash Data

It is a new crash signature that appeared in 4.0b11. It is #9 top crasher on Mac OS X in 4.0b11. Signature CopyUnicodeTo UUID 00cba18c-7a57-43c0-8802-20bd52110210 Time 2011-02-10 00:43:35.243436 Uptime 584 Last Crash 5481378 seconds (9.1 weeks) before submission Install Age 584 seconds (9.7 minutes) since version was first installed. Product Firefox Version 4.0b11 Build ID 20110203140743 Branch 2.0 OS Mac OS X OS Version 10.6.4 10F569 CPU x86 CPU Info family 6 model 14 stepping 8 Crash Reason EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE Crash Address 0x1c08160 User Comments mozilla addon page App Notes Renderers: 0x21900,0x20400 Frame Module Signature [Expand] Source 0 @0xffff0929 1 XUL CopyUnicodeTo nsCharTraits.h:217 2 XUL XPCStringConvert::ReadableToJSVal js/src/xpconnect/src/xpcstring.cpp:128 3 XUL XPCConvert::NativeData2JS js/src/xpconnect/src/xpcconvert.cpp:353 4 XUL nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcprivate.h:3203 5 XUL nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:588 6 XUL PrepareAndDispatch xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 7 XUL nsXPTCStubBase::Stub12 xptcstubsdef.inc:10 8 XUL nsDocument::InitCSP content/base/src/nsDocument.cpp:2438 9 XUL nsDocument::StartDocumentLoad content/base/src/nsDocument.cpp:2392 10 XUL nsHTMLDocument::StartDocumentLoad content/html/document/src/nsHTMLDocument.cpp:724 11 XUL nsContentDLF::CreateDocument layout/build/nsContentDLF.cpp:470 12 XUL nsContentDLF::CreateInstance layout/build/nsContentDLF.cpp:301 13 XUL nsDocShell::NewContentViewerObj docshell/base/nsDocShell.cpp:7519 14 XUL nsDocShell::CreateContentViewer docshell/base/nsDocShell.cpp:7328 15 XUL nsDSURIContentListener::DoContent docshell/base/nsDSURIContentListener.cpp:148 16 XUL nsDocumentOpenInfo::TryContentListener uriloader/base/nsURILoader.cpp:757 17 XUL nsDocumentOpenInfo::DispatchContent uriloader/base/nsURILoader.cpp:455 18 XUL nsDocumentOpenInfo::OnStartRequest uriloader/base/nsURILoader.cpp:295 19 XUL nsHttpChannel::CallOnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:770 20 XUL nsHttpChannel::ContinueProcessNormal netwerk/protocol/http/nsHttpChannel.cpp:1221 21 XUL nsHttpChannel::ProcessNormal netwerk/protocol/http/nsHttpChannel.cpp:1158 22 XUL nsHttpChannel::ProcessResponse netwerk/protocol/http/nsHttpChannel.cpp:1108 23 XUL nsHttpChannel::OnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:3869 24 XUL nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:441 25 XUL nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:112 26 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:633 27 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:200 28 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:132 29 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:399 30 CoreFoundation __CFRunLoopDoSources0 31 CoreFoundation __CFRunLoopRun 32 CoreFoundation CFRunLoopRunSpecific 33 CoreFoundation CFRunLoopRunInMode 34 HIToolbox RunCurrentEventLoopInMode 35 HIToolbox ReceiveNextEventCommon 36 HIToolbox BlockUntilNextEventMatchingListInMode 37 AppKit _DPSNextEvent 38 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 39 AppKit -[NSApplication run] 40 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:746 41 XUL nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:218 42 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3775 43 firefox-bin main browser/app/nsBrowserApp.cpp:158 44 firefox-bin firefox-bin@0xa05 45 @0x1 More reports at: https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=4&range_unit=weeks&signature=CopyUnicodeTo
Assignee: nobody → lw
Is it possible to figure out in which nightly this signature first appeared? I'd like a more specific regression window if possible. At first glance this appears unrelated to XPConnect, and probably related to some CSP change. Although looking at the stack, the DOM code is calling http://hg.mozilla.org/mozilla-central/annotate/f9d66f4d17bf/content/base/src/nsDocument.cpp#l2438 nsIContentSecurityPolicy.scanRequestData. And for some reason xpconnect is trying to convert a unicode string, even though the only parameter is an nsIHttpChannel. I wonder if there's a UUID conflict or if the interface info is royally screwed up. I do note that the IID of nsIContentSecurityPolicy was apparently copy-pasted as the CID of the contentsecuritypolicy impl, which is horrible code hygiene but shouldn't actually cause problems: http://mxr.mozilla.org/mozilla-central/search?string=AB36A2BF scoobidiver, it's a bit strange that this bug is mac-only. Do you see any new Windows crash signatures which might be the same issue under a different signature? I looked for nsCharTraits/memmove/
Keywords: regressionwindow-wanted
> Do you see any new Windows crash signatures which might be the same issue under > a different signature? No. > it's a bit strange that this bug is mac-only. May be because there is no 64-bit Beta 11 build on Windows. See the CPU correlation: 100% (20/20) vs. 41% (445/1077) amd64 with 2 cores
I don't think that says much, because pretty much all macs have 64-bit processors. Unless we actually get different processor data when we're running in 32-bit mode...
We do appear to. Although the x86 population is small enough that I'm not sure it is statistically relevant yet.
> I don't think that says much, because pretty much all macs have 64-bit > processors. Using the processor crash correlations: 0% (0/20) vs. 0% (3/1077) x86 with 1 cores 0% (0/20) vs. 0% (3/1077) x86 with 16 cores 0% (0/20) vs. 1% (14/1077) x86 with 8 cores 0% (0/20) vs. 3% (35/1077) x86 with 4 cores 0% (0/20) vs. 38% (405/1077) x86 with 2 cores 43% of Mac crash reports has a 32-bit processor. It is statistically relevant.
Yes, we report the CPU architecture that the binary is running as. I would expect that almost everyone on 10.6 would be amd64, since that's the default, and everyone on 10.5 on x86 since we dropped ppc builds.
We touched the surrounding code recently but if its not us, even better.
Assignee: lw → nobody
gal, which changes are you referring to? I'd like to read them over.
The change I suspect gal was blaming me for just merged to m-c today, so that's clearly not in b11.
I found a Windows crash ([@ ToNewUnicode(nsACString_internal const&) ]) in 64-bit nightly builds: bp-c034437e-8ffd-4414-a953-37c142110211 Is it related?
I don't think that win64 crash is related, its real stack according to MSVC is xul.dll!ToNewUnicode(aSource={...}) Line 378 C++ xul.dll!XPCConvert::NativeData2JS(lccx={...}, d=0xfffb000000000001, s=0x0000000000000000, type={...}, iid=0x0000000000405dd8, scope=0x00000000124a58f0, pErr=0x0000000000000000) Line 444 C++ xul.dll!XPCConvert::NativeData2JS(ccx={...}, d=0xfffb000000000000, s=0x00000000067a1206, type={...}, iid=0x0000000000405dd8, scope=0x00000000124a58f0, pErr=0x0000000000000000) Line 3211 C++ xul.dll!nsXPCWrappedJSClass::CallMethod(wrapper=0x000007fee8c06541, methodIndex=0x003f, info=0x0000000000406120, nativeParams=0x0000000000406160) Line 1595 C++ xul.dll!nsXPCWrappedJS::CallMethod(methodIndex=0x6160, info=0x0000000000406238, params=0x0000000000000003) Line 589 C++ xul.dll!PrepareAndDispatch(self=0x00000000026d70b0, methodIndex=0x0a3d87c0, args=0x0000000000050080, gprData=0x00000000186fd268, fprData=0x0000000000406250) Line 201 C++ xul.dll!SharedStub() Asm > xul.dll!nsNavBookmarks::NotifyItemChanged(aData={...}) Line 2935 C++ xul.dll!`anonymous namespace'::AsyncGetBookmarksForURI<void (__cdecl nsNavBookmarks::*)(mozilla::places::ItemVisitData const & __ptr64) __ptr64,mozilla::places::ItemVisitData>::HandleResult(aResultSet=0x000000000a392920) Line 154 C++ And that call actually does have a string parameters.
Did we recently take some changes to the x64 xpconnect stuff, from Rafael?
My patch was the 236989b3a807, but the file is named xptcinvoke_x86_64_unix, so I don't think it is related to a windows crash.
This bug is not about a Windows crash, it is about the mac crash.
But that bug didn't land for b11, so it's probably not a candidate here.
Possibly related: bug 627227. I don't have many other good candidates. Or GC components.
Compartments, I mean.
Assignee: nobody → chofmann
blocking2.0: ? → final+
Whiteboard: [softblocker]
(In reply to comment #1) > Is it possible to figure out in which nightly this signature first appeared? It looks to me like this is the kind of bug that takes over 100,000 beta testers before it shows up. b11 released on feb8, and by feb9 we had 276,823 ADUs. CopyUnicodeTo date total breakdown by build crashes count build, count build, ... 20110204 20110205 20110206 20110207 20110208 2 4.0b11^\2011020314 2 , 20110209 21 4.0b11^\2011020314 21 , 20110210 23 4.0b11^\2011020314 23 , 20110211 10 4.0b11^\2011020314 10 , 20110212 11 4.0b11^\2011020314 11 , 20110213 7 4.0b11^\2011020314 7 , 20110214 7 4.0b11^\2011020314 7 , It spiked in early days after the release but seems to have tailed off in the last few days, even though the beta test population on feb14 had grown to 1.4 Milliion ADUs
(In reply to comment #1) > > scoobidiver, it's a bit strange that this bug is mac-only. Do you see any new > Windows crash signatures which might be the same issue under a different > signature? I looked for nsCharTraits/memmove/ I spotted a similar memmove sig but the stacks there look varied and not much like the one in comment 0. 4 CopyUnicodeTo(nsScannerIterator const&, nsScannerIterator const&, nsAString_internal&) 2 memmove | CopyUnicodeTo(nsScannerIterator const&, nsScannerIterator const&, nsAString_internal&) Its low volume. More reports at: https://crash-stats.mozilla.com/report/list?signature=memmove%20|%20CopyUnicodeTo%28nsScannerIterator%20const%26%2C%20nsScannerIterator%20const%26%2C%20nsAString_internal%26%29
I'd say give the info here this shouldn't be a 2.0 final blocker and maybe should be moved out to be looked at in a later release. We should keep any eye out on any volume changes.
Comment 20 is irrelevant, that's a different function entirely. I'll minus it for now.
blocking2.0: final+ → .x
Whiteboard: [softblocker]
Comment 23 is also irrelevant, a crash at ToNewUnicode in places code, not CopyUnicodeTo, and in places code instead of nsDocument::InitCSP.
There have been no crashes in 4.0b12 so far. I think it is fixed.
Hardware: x86_64 → All
Summary: Crash [@ CopyUnicodeTo ] → Crash in nsDocument::InitCSP [@ CopyUnicodeTo ]
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ CopyUnicodeTo ]
You need to log in before you can comment on or make changes to this bug.