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)

defect
Not set
critical

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.
Attached file Backtacefromcrash
Seems to  work  with plain Mozilla
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 ]
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.
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??
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. 
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  ...
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.
I have added that change, but the same crash occurs.I  will try with
updated source.
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.
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.
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?
bug 234622 might be related
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
This crash no longer occurs
Crash Signature: [@ nsJAR::ParseManifest ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: