Closed
Bug 229845
Opened 21 years ago
Closed 20 years ago
Crash whilst loading Remote Xul example on bugzilla [@ nsJAR::ParseManifest ]
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
DUPLICATE
of bug 231709
People
(Reporter: bfowler, Assigned: bugzilla)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20030511 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20030511 Firebird/0.7+ This page, linked from http://www.mozillazine.org/talkback.html?article=2722 causes the browser to crash. I could do this three times out of three, after updating sources from CVS and recompiling. Reproducible: Always Steps to Reproduce: 1. Go to http://www.mozillazine.org/talkback.html?article=2722 2. Click on the link XUL version of the Bugzilla duplicates report 3. Actual Results: Firebird crashes Expected Results: The page should have downloaded and displayed in some way. If there is a problem (version, brand or security mismatch) then there should be a dialog or some error message. Stack trace to follow. This may a minor problem, Firebird is a moving target and the page may be old.
Reporter | ||
Comment 1•21 years ago
|
||
Reporter | ||
Comment 2•21 years ago
|
||
Seems to work with plain Mozilla
Comment 3•21 years ago
|
||
confirming using 20031231 on Linux.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
OS: MacOS X → All
Hardware: Macintosh → All
Summary: Crash whilst loading Remote Xul example on bugzilla → Crash whilst loading Remote Xul example on bugzilla [@ nsJAR::ParseManifest ]
Reporter | ||
Comment 4•21 years ago
|
||
I erred in exculpating the traditional Mozilla. Mozilla compiled from current sources behaves in the same way as Firebird, as the attached backtrace shows. This is perhaps a regression probably some time since Christmas Eve.
Reporter | ||
Comment 5•21 years ago
|
||
In case it is not obvious from the info so far, note that the function nsNSSComponent::VerifySignature( ) has returned NS_OK before the crash, which I would guess is a failled attempt to assign to the nsIPrincipal* mPrincipal through an nsIPrincipal** on the stack. Buffer overflow??
Reporter | ||
Comment 6•21 years ago
|
||
Not quite. The assignment is carried out correctly, the function nsNSSComponent::VerifySignature( ) returns, and the stack is OK for at least one machine instruction, but attempting even one 'step' leads to the pc containing garbage. Stand by.
Reporter | ||
Comment 7•21 years ago
|
||
I'm stymied. See http://lxr.mozilla.org/mozilla/source/modules/libjar/nsJAR.cpp#601 At the machine code level, straight after the return from rv = verifier->VerifySignature(sigBuffer, sigLen, manifestBuffer, manifestLen, &verifyError, getter_AddRefs(mPrincipal)); the code calls the getter_AddRefs destructor,and this is where the crash occurs. I cannot see how the problem arises. The program appears to fail between the lines. The code for the destructor is in nsCOMPtr.h,and is presumably well tested. We eventually come to line 551, and I suppose that it is possible that NS_GET_IID(T) might misbehave ...
Comment 8•21 years ago
|
||
It's crashing in a little different place in a newer build: Program received signal EXC_BAD_ACCESS, Could not access memory. 0xfffffffc in ?? () (gdb) bt #0 0xfffffffc in ?? () Cannot access memory at address 0xfffffffc Cannot access memory at address 0xfffffffc #1 0x00d846f4 in unsigned ns_if_addref<nsIPrincipal*>(nsIPrincipal*) (expr=0x1b35af30) at ../../dist/include/xpcom/nsISupportsUtils.h:114 #2 0x0015762c in nsJARChannel::GetOwner(nsISupports**) (this=0x1bfe5fc0, result=0xbfffdd40) at nsJARChannel.cpp:417 #3 0x003ba12c in nsXULDocument::PrepareToLoad(nsISupports*, char const*, nsIChannel*, nsILoadGroup*, nsIParser**) (this=0x1bfba4f0, aContainer=0x1aad1264, aCommand=0xd3464c "view", aChannel=0x1bfe5fc0, aLoadGroup=0x1aad3b90, aResult=0xbfffde10) at nsXULDocument.cpp:2373 #4 0x003b3a2c in nsXULDocument::StartDocumentLoad(char const*, nsIChannel*, nsILoadGroup*, nsISupports*, nsIStreamListener**, int, nsIContentSink*) (this=0x1bfba4f0, aCommand=0xd3464c "view", aChannel=0x1bfe5fc0, aLoadGroup=0x1aad3b90, aContainer=0x1aad1264, aDocListener=0x1c001ecc, aReset=1, aSink=0x0) at nsXULDocument.cpp:642 #5 0x004cef2c in nsContentDLF::CreateRDFDocument(char const*, nsIChannel*, nsILoadGroup*, char const*, nsISupports*, nsISupports*, nsIStreamListener**, nsIContentViewer**) (this=0x1a3122b0, aCommand=0xd3464c "view", aChannel=0x1bfe5fc0, aLoadGroup=0x1aad3b90, aContentType=0x1a66c880 "application/vnd.mozilla.xul+xml", aContainer=0x1aad1264, aExtraInfo=0x0, aDocListener=0x1c001ecc, aDocViewer=0xbfffe1b0) at nsContentDLF.cpp:524 #6 0x004cdf68 in nsContentDLF::CreateInstance(char const*, nsIChannel*, nsILoadGroup*, char const*, nsISupports*, nsISupports*, nsIStreamListener**, nsIContentViewer**) (this=0x1a3122b0, aCommand=0xd3464c "view", aChannel=0x1bfe5fc0, aLoadGroup=0x1aad3b90, aContentType=0x1a66c880 "application/vnd.mozilla.xul+xml", aContainer=0x1aad1264, aExtraInfo=0x0, aDocListener=0x1c001ecc, aDocViewer=0xbfffe1b0) at nsContentDLF.cpp:257 #7 0x0087694c in nsDocShell::NewContentViewerObj(char const*, nsIRequest*, nsILoadGroup*, nsIStreamListener**, nsIContentViewer**) (this=0x1aad1240, aContentType=0x1a66c880 "application/vnd.mozilla.xul+xml", request=0x1bfe5fc0, aLoadGroup=0x1aad3b90, aContentHandler=0x1c001ecc, aViewer=0xbfffe1b0) at nsDocShell.cpp:4608 #8 0x00876000 in nsDocShell::CreateContentViewer(char const*, nsIRequest*, nsIStreamListener**) (this=0x1aad1240, aContentType=0x1a66c880 "application/vnd.mozilla.xul+xml", request=0x1bfe5fc0, aContentHandler=0x1c001ecc) at nsDocShell.cpp:4473 #9 0x00885290 in nsDSURIContentListener::DoContent(char const*, int, nsIRequest*, nsIStreamListener**, int*) (this=0x1aada4e0, aContentType=0x1a66c880 "application/vnd.mozilla.xul+xml", aIsContentPreferred=1, request=0x1bfe5fc0, aContentHandler=0x1c001ecc, aAbortProcess=0xbfffe340) at nsDSURIContentListener.cpp:109 #10 0x008490b4 in nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (this=0x1c001ec0, aListener=0x1aada4e0, aChannel=0x1bfe5fc0) at nsURILoader.cpp:669 #11 0x00848248 in nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (this=0x1c001ec0, request=0x1bfe5fc0, aCtxt=0x0) at nsURILoader.cpp:413 #12 0x00847c08 in nsDocumentOpenInfo::OnStartRequest(nsIRequest*, nsISupports*) (this=0x1c001ec0, request=0x1bfe5fc0, aCtxt=0x0) at nsURILoader.cpp:287 #13 0x00158434 in nsJARChannel::OnStartRequest(nsIRequest*, nsISupports*) (this=0x1bfe5fc0, req=0x1b360470, ctx=0x0) at nsJARChannel.cpp:641 #14 0x001053a0 in nsInputStreamPump::OnStateStart() (this=0x1b360470) at nsInputStreamPump.cpp:377 #15 0x00105200 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x1b360470, stream=0x1c008908) at nsInputStreamPump.cpp:333 #16 0x14739ef8 in ?? () at ../../dist/include/xpcom/nsCOMPtr.h:668 #17 0x146af95c in PL_HandleEvent (self=0x1b4df724) at plevent.c:671 #18 0x146af7cc in PL_ProcessPendingEvents (self=0x139f5830) at plevent.c:606 #19 0x146aff68 in _md_EventReceiverProc (nextHandler=0xbfffe9b0, inEvent=0x6e5c0525, userData=0x139f5830) at plevent.c:1565 #20 0x969a2c54 in DispatchEventToHandlers () #21 0x969a2fbc in SendEventToEventTargetInternal () #22 0x969a63d0 in SendEventToEventTargetWithOptions () #23 0x969b2940 in ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) () #24 0x969a2d0c in DispatchEventToHandlers () #25 0x969a2fbc in SendEventToEventTargetInternal () #26 0x969b5494 in SendEventToEventTarget () #27 0x969b7258 in ToolboxEventDispatcher(OpaqueEventRef*) () #28 0x969c8740 in CallEventDispatchHook () #29 0x969b3c90 in TryEventDispatcher () #30 0x969a4570 in GetOrPeekEvent () #31 0x969a4330 in GetNextEventMatchingMask () #32 0x969a8054 in WNEInternal () #33 0x969adf0c in WaitNextEvent () #34 0x00325128 in nsMacMessagePump::GetEvent(EventRecord&) (this=0x13947090, theEvent=@0xbfffef90) at nsMacMessagePump.cpp:407 #35 0x00324f8c in nsMacMessagePump::DoMessagePump() (this=0x13947090) at nsMacMessagePump.cpp:304 #36 0x002fcb60 in nsAppShell::Run() (this=0x13f24c50) at nsAppShell.cpp:112 #37 0x00a0f09c in nsAppShellService::Run() (this=0x13f24be0) at nsAppShellService.cpp:483 #38 0x00cd9d98 in main1(int, char**, nsISupports*, nsXREAppData const&) (argc=3, argv=0xbffff43c, nativeApp=0x13963750, aAppData=@0xbffff340) at nsAppRunner.cpp:1282 #39 0x00cda868 in xre_main(int, char**, nsXREAppData const&) (argc=3, argv=0xbffff43c, aAppData=@0xbffff340) at nsAppRunner.cpp:1725 #40 0x00004870 in main (argc=3, argv=0xbffff43c) at nsBrowserApp.cpp:51 Looks like it's breaking somewhere in GetCertificatePrincipal, while adding a ref. Let's set a breakpoint and try again. Breakpoint 6, nsJAR::GetCertificatePrincipal(char const*, nsIPrincipal**) (this=0x1ae93980, aFilename=0x1aecc9c0 "duplicates.xul", aPrincipal=0xbfffdc60) at nsJAR.cpp:369 369 if (!aPrincipal) (gdb) p aPrincipal $51 = (nsIPrincipal **) 0xbfffdc60 (gdb) p *aPrincipal $52 = (Cannot access memory at address 0x0 n down to line 413... #0 nsJAR::GetCertificatePrincipal(char const*, nsIPrincipal**) (this=0x1ae88c70, aFilename=0x1b0ac480 "duplicates.xul", aPrincipal=0xbfffdc60) at nsJAR.cpp:414 413 *aPrincipal = mPrincipal; 414 NS_IF_ADDREF(*aPrincipal); This is where the crash occurs. Looking at the definition for NS_IF_ADDREF: * Macro for adding a reference to an interface that checks for NULL. * @param _expr The interface pointer. */ #define NS_IF_ADDREF(_expr) ns_if_addref(_expr) /* * Given these declarations, it explicitly OK and efficient to end a `getter' with: * * NS_IF_ADDREF(*result = mThing); * * even if |mThing| is an |nsCOMPtr|. If |mThing| is an |nsCOMPtr|, however, it is still * _illegal_ to say |NS_IF_ADDREF(mThing)|. */ Doh! It looks like that's what's happening. Changing the two lines to: NS_IF_ADDREF(*aPrincipal = mPrincipal); should do the trick... but it doesn't. I'll poke around a bit more.
Reporter | ||
Comment 9•21 years ago
|
||
I have added that change, but the same crash occurs.I will try with updated source.
Reporter | ||
Comment 10•21 years ago
|
||
The problem that I am seeing does seem to be within nsNSSComponent::VerifySignature( ) when I add a quick return: return NS_ERROR_FAILURE; at the top of that function, its caller, nsJAR::ParseManifest runs as I would expect.
Reporter | ||
Comment 11•21 years ago
|
||
I can, in a sense narrow it down to a single source line, videlicet http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSComponent.cpp#1473 If I change that by appending a return statement so that it looks *aPrincipal = certPrincipal; fprintf( stderr, "Quick return from line %d\n", __LINE__ ); return NS_ERROR_FAILURE; } Then the crash still occurs, but it does not, if the 'quick' return is immediately above the assignment. gdb tells me that the machine code for that line is: 0x2389008 <_+2068>: lwz r29,816(r30) 0x238900c <_+2072>: addi r0,r30,208 0x2389010 <_+2076>: mr r3,r0 0x2389014 <_+2080>: bl 0x23ecdf0 <dyld_stub__ZNK8nsCOMPtrI12nsIPrincipalEcvP13nsDerivedSafeIS0_EEv> 0x2389018 <_+2084>: mr r0,r3 0x238901c <_+2088>: stw r0,0(r29) 0x2389020 <_+2092>: addi r0,r30,640 0x2389024 <_+2096>: mr r3,r0 0x2389028 <_+2100>: bl 0x23ecda8 <dyld_stub__ZN27NS_LossyConvertUTF16toASCIID1Ev> 0x238902c <_+2104>: addi r0,r30,496 0x2389030 <_+2108>: mr r3,r0 0x2389034 <_+2112>: bl 0x23ee350 <dyld_stub__ZN12nsAutoStringD1Ev> 0x2389038 <_+2116>: addi r0,r30,208 0x238903c <_+2120>: mr r3,r0 0x2389040 <_+2124>: bl 0x23ecd84 <dyld_stub__ZN8nsCOMPtrI12nsIPrincipalED1Ev> 0x2389044 <_+2128>: addi r0,r30,400 0x2389048 <_+2132>: mr r3,r0 0x238904c <_+2136>: bl 0x23ecda8 <dyld_stub__ZN27NS_LossyConvertUTF16toASCIID1Ev> 0x2389050 <_+2140>: addi r0,r30,256 0x2389054 <_+2144>: mr r3,r0 0x2389058 <_+2148>: bl 0x23ee350 <dyld_stub__ZN12nsAutoStringD1Ev> 0x238905c <_+2152>: addi r0,r30,192 0x2389060 <_+2156>: mr r3,r0 0x2389064 <_+2160>: bl 0x23e9328 <dyld_stub__ZN8nsCOMPtrI11nsIX509CertED1Ev> (I am more used to Jasik than gdb), and I suspect that one of those compiler generated functions needs to be looked at carefully.
Reporter | ||
Comment 12•21 years ago
|
||
I believe that the two functions with 'nsCOMPtrI12nsIPrincipal' in their name are nsCOMPtr constructor and destructor, perhaps used in creating a temporary for the assignment. After the function returns are were calling a destructor on an invalid object? My nsCOMPtr internals knowledge is not up to solving this one off the top of my head. Any hints?
Comment 13•20 years ago
|
||
bug 234622 might be related
Comment 14•20 years ago
|
||
This is fixed in the current trunk, but I don't think firefox has it yet. Get a nightly or wait for the next release. *** This bug has been marked as a duplicate of 231709 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 15•20 years ago
|
||
This crash no longer occurs
Updated•13 years ago
|
Crash Signature: [@ nsJAR::ParseManifest ]
You need to log in
before you can comment on or make changes to this bug.
Description
•