Closed Bug 633450 Opened 13 years ago Closed 13 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: 13 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ CopyUnicodeTo ]
You need to log in before you can comment on or make changes to this bug.