617297 - Fennec 4.0b3pre Crash Report [@ nsXPConnect::GetPrincipal] [@ nsScriptSecurityManager::doGetObjectPrincipal] [@ XPCWrappedNative::GetObjectPrincipal]

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[ahoza]

Device: Samsung Galaxy S
BuildID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b8pre)Gecko/20101205 Firefox/4.0b8pre Fennec /4.0b3pre

Steps to reproduce:

1. Open Fennec.
2. Try to download a file from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Expected results:
Download should start. A notification in the android notification bar should be available.

Actual results:
Tab crashes.

Crash report: http://crash-stats.mozilla.com/report/index/89138fe8-4573-4a14-b7c9-2c7972101207

Comment 1

[Scoobidiver (away)]

It is #7 top crasher in Fennec 4.0b3pre for the last week.
Many crashes happen at startup (uptime=0).

Signature	nsXPConnect::GetPrincipal
UUID	e9177fb3-6b9a-4aaf-a57d-d50ef2101209
Time 	2010-12-09 08:18:07.570720
Uptime	0
Install Age	1471 seconds (24.5 minutes) since version was first installed.
Product	Fennec
Version	4.0b3pre
Build ID	20101209042810
Branch	2.0
OS	Linux
OS Version	0.0.0 Linux 2.6.29 #2 Tue Sep 28 18:39:10 KST 2010 armv7l
CPU	arm
CPU Info	
Crash Reason	SIGSEGV
Crash Address	0xbe2d1fe8

Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	nsXPConnect::GetPrincipal 	js/src/xpconnect/src/nsXPConnect.cpp:2543
1 	libxul.so 	nsScriptSecurityManager::doGetObjectPrincipal 	caps/src/nsScriptSecurityManager.cpp:2419
2 	libxul.so 	nsScriptSecurityManager::GetFunctionObjectPrincipal 	caps/src/nsScriptSecurityManager.cpp:2225
3 	libxul.so 	nsScriptSecurityManager::GetFramePrincipal 	caps/src/nsScriptSecurityManager.cpp:2260
4 	libxul.so 	nsScriptSecurityManager::GetPrincipalAndFrame 	caps/src/nsScriptSecurityManager.cpp:2293
5 	libxul.so 	nsScriptSecurityManager::GetSubjectPrincipal 	caps/src/nsScriptSecurityManager.cpp:2353
6 	libxul.so 	nsScriptSecurityManager::CheckPropertyAccessImpl 	caps/src/nsScriptSecurityManager.cpp:693
7 	libxul.so 	nsScriptSecurityManager::CheckPropertyAccess 	caps/src/nsScriptSecurityManager.cpp:614
8 	libxul.so 	nsScriptSecurityManager::CheckObjectAccess 	caps/src/nsScriptSecurityManager.cpp:578
9 	libxul.so 	InitExnPrivate 	js/src/jsexn.cpp:301
10 	libxul.so 	js_ErrorToException 	js/src/jsexn.cpp:1193
11 	libxul.so 	js_ReportErrorNumberVA 	js/src/jscntxt.cpp:1329
12 	libxul.so 	JS_ReportErrorNumber 	js/src/jsapi.cpp:5541
13 	libxul.so 	js_ReportOverRecursed 	js/src/jscntxt.cpp:1420
14 	libxul.so 	js::Interpret 	js/src/jsinterp.cpp:2340
15 	libxul.so 	js::Invoke 	js/src/jsinterp.cpp:657
16 	libxul.so 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
17 	libxul.so 	JS_CallFunctionValue 	js/src/jsinterp.h:962
18 	libxul.so 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696
19 	libxul.so 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:589
20 	libxul.so 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:134
21 	libxul.so 	libxul.so@0x955974 	
22 	libxul.so 	nsExternalHelperAppService::GetTypeFromExtension 	uriloader/exthandler/nsExternalHelperAppService.cpp:2738
23 		@0x42dd2bdf 	
24 	libxul.so 	nsExternalHelperAppService::GetTypeFromURI 	uriloader/exthandler/nsExternalHelperAppService.cpp:2827
25 	libxul.so 	nsUnknownDecoder::SniffURI 	netwerk/streamconv/converters/nsUnknownDecoder.cpp:542
26 	libxul.so 	nsUnknownDecoder::DetermineContentType 	netwerk/streamconv/converters/nsUnknownDecoder.cpp:383
27 	libxul.so 	nsUnknownDecoder::OnDataAvailable 	netwerk/streamconv/converters/nsUnknownDecoder.cpp:185
28 	libxul.so 	nsDocumentOpenInfo::OnDataAvailable 	uriloader/base/nsURILoader.cpp:325
....

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=nsXPConnect%3A%3AGetPrincipal&version=Fennec%3A4.0b3pre

Comment 2

[Josh Matthews [:jdm]]

I can reproduce on my and will be investigating it as soon as I can get someone to help me upgrade to 2.2 so I can make gdb work.

Comment 3

[Josh Matthews [:jdm]]

This continues to be the #4 topcrash, and is much higher if you also include the nsScriptSecurityManager::doGetObjectPrincipal and XPCWrappedNative::GetObjectPrincipal signatures as well.

Comment 4

[Brian Crowder]

jdm:  Can you add your steps to reproduce here?

Comment 5

[Josh Matthews [:jdm]]

I believe I tried downloading a file which didn't have a default handler (such as a tar, perhaps?).

Comment 6

[Brian Crowder]

fwiw, this crash only occurs if you use the ftp protocol, not http.

Comment 8

[Brian Crowder]

This seems to have gone away since 1/4/2011, please reopen if that is not the case.

Comment 9

[ahoza]

I'm still getting the crash report with latest trunk build on Motorola Droid 2, HTC Desire A8181 using STR in comment 0
Reopening the bug.

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

there has only been one crash report with this signature in the year 2011

Comment 11

[Alex Pakhotin (:alexp)]

I don't get a crash, but the file does not download. I get the following error: "Sorry! Something went wrong while displaying a web page." with "Close tab" & "Reload tab" buttons.
Looks like it's a different issue, though might be related.

Comment 12

[Josh Matthews [:jdm]]

Alex, that's the content crash dialog.  If you look in about:crashes, there should be a new report that is linked to this big.

Comment 13

[Alex Pakhotin (:alexp)]

Thanks, I suspected that's the crash, but I don't see any crash reports on that page. Probably something is different in my local build (crash reporter disabled?).

Comment 14

[Josh Matthews [:jdm]]

This isn't related to JS, per-se.  This is just an infinite recursion problem that ends up breaking... something?  I guess ideally we wouldn't bail at some point while reporting the exception, but that's not really the main problem here in my eyes.

Comment 15

[Alex Pakhotin (:alexp)]

I'm consistently getting the crash stacks like this:
=======================================
#0  0xafd0ec9c in kill () from /media/mozilla/debug/lib/libc.so
#1  0xafd13746 in raise () from /media/mozilla/debug/lib/libc.so
#2  0x82ee5a02 in JS_Assert (s=<value optimized out>, file=<value optimized out>, ln=<value optimized out>) at /media/mozilla/mozilla-central/js/src/jsutil.cpp:83
#3  0x82e429c6 in js_GC (cx=0x422444e0) at /media/mozilla/mozilla-central/js/src/jsgc.cpp:2777
#4  RunLastDitchGC (cx=0x422444e0) at /media/mozilla/mozilla-central/js/src/jsgc.cpp:1117
#5  0x82e43284 in RefillTypedFreeList<JSString> (cx=0x422444e0, thingKind=6) at /media/mozilla/mozilla-central/js/src/jsgc.cpp:1137
#6  RefillFinalizableFreeList (cx=0x422444e0, thingKind=6) at /media/mozilla/mozilla-central/js/src/jsgc.cpp:1194
#7  0x82ed3318 in js_NewGCString(JSContext*) () from /media/mozilla/mozilla-central/objdir/dist/bin/libxul.so
#8  0x82ece774 in js_NewString (cx=0x422444e0, chars=<value optimized out>, length=45) at /media/mozilla/mozilla-central/js/src/jsstr.cpp:3428
#9  0x82dc2f1c in JS_NewStringCopyZ (cx=0x422444e0, s=<value optimized out>) at /media/mozilla/mozilla-central/js/src/jsapi.cpp:5215
#10 0x82e2b1fc in js_ErrorToException (cx=0x422444e0, message=<value optimized out>, reportp=0xbe58b5e4, callback=<value optimized out>, userRef=0x0) at /media/mozilla/mozilla-central/js/src/jsexn.cpp:1173
#11 0x82df729a in ReportError (cx=0x422444e0, message=0x48f49a00 "too much recursion", reportp=0xbe58b5e4, callback=0x82df6d0d <js_GetErrorMessage(void*, char const*, uintN const)>, userRef=0x0) at /media/mozilla/mozilla-central/js/src/jscntxt.cpp:1290
#12 0x82df9832 in js_ReportErrorNumberVA (cx=0x422444e0, flags=<value optimized out>, callback=0x82df6d0d <js_GetErrorMessage(void*, char const*, uintN const)>, userRef=0x0, errorNumber=26, charArgs=1, ap=...) at /media/mozilla/mozilla-central/js/src/jscntxt.cpp:1643
#13 0x82dc28de in JS_ReportErrorNumber (cx=0x0, errorCallback=0x83571d40, userRef=0x0, errorNumber=2203523124) at /media/mozilla/mozilla-central/js/src/jsapi.cpp:5661
#14 0x82df7062 in js_ReportOverRecursed (cx=0x0) at /media/mozilla/mozilla-central/js/src/jscntxt.cpp:1380
#15 0x82ff0a12 in js::Interpret (cx=0x422444e0, entryFrame=<value optimized out>, inlineCallCount=Cannot access memory at address 0x6) at /media/mozilla/mozilla-central/js/src/jsinterp.cpp:2608
#16 0x82e494e4 in js::RunScript (cx=0x422444e0, script=0x42240640, fp=0x42620038) at /media/mozilla/mozilla-central/js/src/jsinterp.cpp:661
#17 0x82e4c9c4 in js::Invoke (cx=0x422444e0, argsRef=<value optimized out>, flags=0) at /media/mozilla/mozilla-central/js/src/jsinterp.cpp:741
#18 0x82e4cea8 in js::ExternalInvoke (cx=0x422444e0, thisv=..., fval=..., argc=1119491272, argv=0xbe58bdf8, rval=0xbe58bed0) at /media/mozilla/mozilla-central/js/src/jsinterp.cpp:862
#19 0x82dcf7d6 in JS_CallFunctionValue (cx=0x422444e0, obj=0x42ba14c8, fval=..., argc=1, argv=0xbe58bdf8, rval=0xbe58bed0) at /media/mozilla/mozilla-central/js/src/jsapi.cpp:5053
#20 0x829713ac in nsXPCWrappedJSClass::CallMethod (this=0x43779d90, wrapper=<value optimized out>, methodIndex=<value optimized out>, info=<value optimized out>, nativeParams=0xbe58bfb8) at /media/mozilla/mozilla-central/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1701
#21 0x8296cab8 in nsXPCWrappedJS::CallMethod (this=0x4370b2c0, methodIndex=8, info=0x410f8210, params=<value optimized out>) at /media/mozilla/mozilla-central/js/src/xpconnect/src/xpcwrappedjs.cpp:588
#22 0x82d07970 in PrepareAndDispatch (self=<value optimized out>, methodIndex=<value optimized out>, args=0xbe58c078) at /media/mozilla/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:132
#23 0x82d06f68 in SharedStub () from /media/mozilla/mozilla-central/objdir/dist/bin/libxul.so
=======================================
The steps to reproduce are as described, and it seems to happen with the files without a standard handler, as mentioned in the comment 5. Text files open in the browser, *.zip are downloading, but *.checksum or *.mar result in this crash.

Comment 16

[Josh Matthews [:jdm]]

That crash stack isn't a surprise, and it reflects the ones we're seeing on crash-stats.  I'm most interested in setting breakpoints in nsDocumentOpenInfo::OnDataAvailable and nsUnknownDecoder::OnDataAvailable and looking at the backtraces from when we start to enter that endless recusion.

Comment 17

[Alex Pakhotin (:alexp)]

Attachment: [WIP] Buffer size fix

The endless recursion starts when nsUnknownDecoder::OnDataAvailable gets called with aCount argument greater than the MAX_BUFFER_SIZE:

======================================================
...
#7086 0x822640ac in nsUnknownDecoder::OnDataAvailable (this=0x436249a0, request=<value optimized out>, aCtxt=<value optimized out>, 
    aStream=<value optimized out>, aSourceOffset=1536, aCount=866)
    at /media/data/mozilla/mozilla-central/netwerk/streamconv/converters/nsUnknownDecoder.cpp:195
#7087 0x829f1388 in nsDocumentOpenInfo::OnDataAvailable (this=0x800, request=<value optimized out>, aCtxt=0x0, inStr=0x43045d90, sourceOffset=1024, 
    count=866) at /media/data/mozilla/mozilla-central/uriloader/base/nsURILoader.cpp:323
#7088 0x822640ac in nsUnknownDecoder::OnDataAvailable (this=0x43624850, request=<value optimized out>, aCtxt=<value optimized out>, 
    aStream=<value optimized out>, aSourceOffset=1024, aCount=866)
    at /media/data/mozilla/mozilla-central/netwerk/streamconv/converters/nsUnknownDecoder.cpp:195
#7089 0x829f1388 in nsDocumentOpenInfo::OnDataAvailable (this=0x600, request=<value optimized out>, aCtxt=0x0, inStr=0x43045d90, sourceOffset=512, 
    count=866) at /media/data/mozilla/mozilla-central/uriloader/base/nsURILoader.cpp:323
#7090 0x822640ac in nsUnknownDecoder::OnDataAvailable (this=0x42d32700, request=<value optimized out>, aCtxt=<value optimized out>, 
    aStream=<value optimized out>, aSourceOffset=512, aCount=866)
    at /media/data/mozilla/mozilla-central/netwerk/streamconv/converters/nsUnknownDecoder.cpp:195
#7091 0x829f1388 in nsDocumentOpenInfo::OnDataAvailable (this=0x400, request=<value optimized out>, aCtxt=0x0, inStr=0x43045d90, sourceOffset=0, 
    count=1378) at /media/data/mozilla/mozilla-central/uriloader/base/nsURILoader.cpp:323
#7092 0x822974f8 in mozilla::net::FTPChannelChild::DoOnDataAvailable (this=0x41071370, data=<value optimized out>, offset=<value optimized out>, 
    count=@0xbedbc9f0) at /media/data/mozilla/mozilla-central/netwerk/protocol/ftp/FTPChannelChild.cpp:342
#7093 0x822975fa in mozilla::net::FTPChannelChild::RecvOnDataAvailable (this=0x200, data=<value optimized out>, offset=@0x80226c64, count=@0xbedbc9f0)
    at /media/data/mozilla/mozilla-central/netwerk/protocol/ftp/FTPChannelChild.cpp:310
#7094 0x82cade00 in mozilla::net::PFTPChannelChild::OnMessageReceived (this=0x41071370, __msg=<value optimized out>) at PFTPChannelChild.cpp:286
#7095 0x82c6f824 in mozilla::dom::PContentChild::OnMessageReceived (this=0x41015188, __msg=...) at PContentChild.cpp:949
#7096 0x82be293a in mozilla::ipc::AsyncChannel::OnDispatchMessage (this=0x41015190, msg=...)
    at /media/data/mozilla/mozilla-central/ipc/glue/AsyncChannel.cpp:262
#7097 0x82be5f4a in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x41015190) at /media/data/mozilla/mozilla-central/ipc/glue/RPCChannel.cpp:433
#7098 0x82be6a94 in DispatchToMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)()> (this=<value optimized out>)
    at /media/data/mozilla/mozilla-central/ipc/chromium/src/base/tuple.h:383
#7099 RunnableMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)(), Tuple0>::Run (this=<value optimized out>)
    at /media/data/mozilla/mozilla-central/ipc/chromium/src/base/task.h:307
#7100 0x82be6ad6 in Run (this=0x42eb7500) at ../../dist/include/mozilla/ipc/RPCChannel.h:450
#7101 mozilla::ipc::RPCChannel::DequeueTask::Run (this=0x42eb7500) at ../../dist/include/mozilla/ipc/RPCChannel.h:475
...
======================================================

This patch, which just increases the buffer size, makes it go further, but does not solve the actual issue.
With the patch applied the recursion seems to be in OnStopRequest:

======================================================
...
#1515 0x82263fdc in nsUnknownDecoder::OnStopRequest (this=<value optimized out>, request=0x411713b8, aCtxt=<value optimized out>, aStatus=0)
    at /media/data/mozilla/mozilla-central/netwerk/streamconv/converters/nsUnknownDecoder.cpp:252
#1516 0x829f1c08 in nsDocumentOpenInfo::OnStopRequest (this=<value optimized out>, request=0x411713b8, aCtxt=0x0, aStatus=<value optimized out>)
    at /media/data/mozilla/mozilla-central/uriloader/base/nsURILoader.cpp:342
#1517 0x82263fdc in nsUnknownDecoder::OnStopRequest (this=<value optimized out>, request=0x411713b8, aCtxt=<value optimized out>, aStatus=0)
    at /media/data/mozilla/mozilla-central/netwerk/streamconv/converters/nsUnknownDecoder.cpp:252
#1518 0x829f1c08 in nsDocumentOpenInfo::OnStopRequest (this=<value optimized out>, request=0x411713b8, aCtxt=0x0, aStatus=<value optimized out>)
    at /media/data/mozilla/mozilla-central/uriloader/base/nsURILoader.cpp:342
#1519 0x82263fdc in nsUnknownDecoder::OnStopRequest (this=<value optimized out>, request=0x411713b8, aCtxt=<value optimized out>, aStatus=0)
    at /media/data/mozilla/mozilla-central/netwerk/streamconv/converters/nsUnknownDecoder.cpp:252
#1520 0x829f1c08 in nsDocumentOpenInfo::OnStopRequest (this=<value optimized out>, request=0x411713b8, aCtxt=0x0, aStatus=<value optimized out>)
    at /media/data/mozilla/mozilla-central/uriloader/base/nsURILoader.cpp:342
#1521 0x8229738e in mozilla::net::FTPChannelChild::DoOnStopRequest (this=0x41171370, statusCode=@0xbef2aa00)
    at /media/data/mozilla/mozilla-central/netwerk/protocol/ftp/FTPChannelChild.cpp:383
#1522 0x8229743c in mozilla::net::FTPChannelChild::RecvOnStopRequest (this=0x411713b8, statusCode=@0xbef2aa00)
    at /media/data/mozilla/mozilla-central/netwerk/protocol/ftp/FTPChannelChild.cpp:365
#1523 0x82cadfcc in mozilla::net::PFTPChannelChild::OnMessageReceived (this=0x41171370, __msg=<value optimized out>) at PFTPChannelChild.cpp:334
#1524 0x82c6f834 in mozilla::dom::PContentChild::OnMessageReceived (this=0x41115188, __msg=...) at PContentChild.cpp:949
#1525 0x82be294a in mozilla::ipc::AsyncChannel::OnDispatchMessage (this=0x41115190, msg=...)
    at /media/data/mozilla/mozilla-central/ipc/glue/AsyncChannel.cpp:262
#1526 0x82be5f5a in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x41115190) at /media/data/mozilla/mozilla-central/ipc/glue/RPCChannel.cpp:433
#1527 0x82be6aa4 in DispatchToMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)()> (this=<value optimized out>)
    at /media/data/mozilla/mozilla-central/ipc/chromium/src/base/tuple.h:383
#1528 RunnableMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)(), Tuple0>::Run (this=<value optimized out>)
    at /media/data/mozilla/mozilla-central/ipc/chromium/src/base/task.h:307
#1529 0x82be6ae6 in Run (this=0x42facfe0) at ../../dist/include/mozilla/ipc/RPCChannel.h:450
#1530 mozilla::ipc::RPCChannel::DequeueTask::Run (this=0x42facfe0) at ../../dist/include/mozilla/ipc/RPCChannel.h:475
...
======================================================

Rings any bells?

Comment 18

[Josh Matthews [:jdm]]

I still don't understand all the interactions between the uriloader and converters and so forth, but as far as I can see, the problem we're facing is this: the unknown decoder fills its buffer and attempts to determine the content type.  It fails, and it then calls back to nsDocumentOpenInfo (is this sensible? I don't know).  The nsDocumentOpenInfo throws it right back to the decoder, but this time the decoder already has a full buffer, so it decides to read 0 bytes from the stream.  Endgame, right there.  Crowder, any thoughts on what's going on here?

Comment 19

[Alex Pakhotin (:alexp)]

It's all yours, Brian. :)
Sounds like you know this stuff.

Comment 20

[Stuart Parmenter]

#11 top crash for b4

Comment 21

[Brian Crowder]

Not seeing this on the topcrash list anymore, and still cannot reproduce.  Alex, we need to get together to debug on IRC.

Comment 22

[Brad Lassey [:blassey] (use needinfo?)]

crowder, alexp can we get a plan and/or estimate for this? you can ping me on IRC to discuss.

Comment 23

[Alex Pakhotin (:alexp)]

I believe Brian could reproduce it yesterday.

Comment 24

[Brad Lassey [:blassey] (use needinfo?)]

crowder confirms he has a handle on it now, thanks

Comment 25

[Brian Crowder]

Attachment: don't lie, we don't have mimeinfo here

Comment 26

[Brian Crowder]

Attachment: this!

Comment 27

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 514577 [details] [diff] [review]
this!

sr=me.  This is exactly what this return value is for: indicating when you didn't actually get any useful data.

Comment 28

[Brian Crowder]

http://hg.mozilla.org/mozilla-central/rev/0de597a9766c

Argh, landed this with the wrong bug # in the comment.  Alas!