190326 - crash in nsJARChannel.cpp when launching calendar

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[hacker formerly known as [e-mail]]

I first noticed this yesterday.  For some reason, mJarReader is null so the
addref fails. 

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x03f4e2c0 in nsJARInputThunk::GetJarReader (this=0x18477540, result=0xbfffcd38)
at ../../../../../mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp:69
69              NS_ADDREF(*result = mJarReader);
(gdb) p result
$1 = (nsIZipReader **) 0xbfffcd38
(gdb) p mJarReader
$2 = {
  mRawPtr = 0x0
}
(gdb) bt
#0  0x03f4e2c0 in nsJARInputThunk::GetJarReader (this=0x18477540,
result=0xbfffcd38) at
../../../../../mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp:69
#1  0x03f4c9c8 in nsJARChannel::GetContentLength (this=0x18473ce0,
result=0xbfffcdf8) at
../../../../../mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp:516
#2  0x01df6cbc in mozJSSubScriptLoader::LoadSubScript (this=0x18477070) at
../../../../../mozilla/js/src/xpconnect/loader/mozJSSubScriptLoader.cpp:275
#3  0x00da6274 in _XPTC_InvokeByIndex () at ../../dist/include/xpcom/nsIThread.h:48
#4  0x00da529c in XPTC_InvokeByIndex (that=0x18477070, methodIndex=3,
paramCount=1, params=0xbfffd01c) at
../../../../../../../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_ppc_rhapsody.cpp:144
#5  0x01dd9414 in XPCWrappedNative::CallMethod (ccx=@0xbfffd27c,
mode=CALL_METHOD) at
../../../../../mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2023
#6  0x01de8dd8 in XPC_WN_CallMethod (cx=0x1835cf60, obj=0x18360960, argc=1,
argv=0x18474dd4, vp=0xbfffd36c) at
../../../../../mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1292
#7  0x004eff44 in js_Invoke (cx=0x1835cf60, argc=1, flags=0) at
../../../mozilla/js/src/jsinterp.c:839
#8  0x005010d0 in js_Interpret (cx=0x1835cf60, result=0xbfffd7d4) at
../../../mozilla/js/src/jsinterp.c:2803
#9  0x004effd4 in js_Invoke (cx=0x1835cf60, argc=1, flags=0) at
../../../mozilla/js/src/jsinterp.c:856
#10 0x005010d0 in js_Interpret (cx=0x1835cf60, result=0xbfffdcb0) at
../../../mozilla/js/src/jsinterp.c:2803
#11 0x004f083c in js_Execute (cx=0x1835cf60, chain=0x1835f410,
script=0x18490cf0, down=0x0, special=0, result=0xbfffdcb0) at
../../../mozilla/js/src/jsinterp.c:1020
#12 0x004b0374 in JS_ExecuteScript (cx=0x1835cf60, obj=0x1835f410,
script=0x18490cf0, rval=0xbfffdcb0) at ../../../mozilla/js/src/jsapi.c:3277
#13 0x12872dbc in nsJSContext::ExecuteScript (this=0x1835ceb0,
aScriptObject=0x183604f0, aScopeObject=0x1835f410, aRetValue=0x0,
aIsUndefined=0x0) at ../../../../mozilla/dom/src/base/nsJSEnvironment.cpp:846
#14 0x085575cc in nsXULDocument::ExecuteScript (this=0x18353f60,
aScriptObject=0x183604f0) at
../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:5919
#15 0x085571dc in nsXULDocument::OnStreamComplete (this=0x18353f60,
aLoader=0x18389270, context=0x0, aStatus=0, stringLen=33758, string=0x15f28000
"/* ***** BEGIN LICENSE BLOCK *****\n * Version: MPL 1.1/GPL 2.0/LGPL 2.1\n *\n
* The contents of this file are subject to the Mozilla Public License Version\n
* 1.1 (the \"License\"); you may not use this f"...) at
../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:5832
#16 0x03eb1938 in nsStreamLoader::OnStopRequest (this=0x18389270,
request=0x18389480, ctxt=0x0, aStatus=0) at
../../../../mozilla/netwerk/base/src/nsStreamLoader.cpp:142
#17 0x03f4d21c in nsJARChannel::OnStopRequest (this=0x18389480, req=0x18389ba0,
ctx=0x0, status=0) at
../../../../../mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp:637
#18 0x03e8515c in nsInputStreamPump::OnStateStop (this=0x18389ba0) at
../../../../mozilla/netwerk/base/src/nsInputStreamPump.cpp:424
#19 0x03e84b64 in nsInputStreamPump::OnInputStreamReady (this=0x18389ba0,
stream=0x18389c3c) at ../../../../mozilla/netwerk/base/src/nsInputStreamPump.cpp:319
#20 0x00d3c12c in nsInputStreamReadyEvent::EventHandler (plevent=0x183768f0) at
../../../mozilla/xpcom/io/nsStreamUtils.cpp:101
#21 0x00d6aa1c in PL_HandleEvent (self=0x183768f0) at
../../../mozilla/xpcom/threads/plevent.c:663
#22 0x00d6a79c in PL_ProcessPendingEvents (self=0x2ba860) at
../../../mozilla/xpcom/threads/plevent.c:593
#23 0x00d6b180 in _md_EventReceiverProc (nextHandler=0xbfffe248,
inEvent=0x6d278d5d, userData=0x2ba860) at
../../../mozilla/xpcom/threads/plevent.c:1541
#24 0x73118b18 in DispatchEventToHandlers ()
#25 0x73101da8 in SendEventToEventTargetInternal ()
#26 0x73150048 in SendEventToEventTargetWithOptions ()
#27 0x731ac108 in ToolboxEventDispatcherHandler ()
#28 0x73118bc4 in DispatchEventToHandlers ()
#29 0x73101da8 in SendEventToEventTargetInternal ()
#30 0x731b65c8 in SendEventToEventTarget ()
#31 0x731d2904 in ToolboxEventDispatcher ()
#32 0x731cfc70 in CallEventDispatchHook ()
#33 0x73179478 in GetOrPeekEvent ()
#34 0x731a1478 in GetNextEventMatchingMask ()
#35 0x731ae418 in WNEInternal ()
#36 0x731c5518 in WaitNextEvent ()
#37 0x0e472224 in nsMacMessagePump::GetEvent (this=0x43d080,
theEvent=@0xbfffe70c) at ../../../../mozilla/widget/src/mac/nsMacMessagePump.cpp:408
#38 0x0e472090 in nsMacMessagePump::DoMessagePump (this=0x43d080) at
../../../../mozilla/widget/src/mac/nsMacMessagePump.cpp:305
#39 0x0e45b7cc in nsAppShell::Run (this=0x29cdf0) at
../../../../mozilla/widget/src/mac/nsAppShell.cpp:120
#40 0x0d4e9e0c in nsAppShellService::Run (this=0x29cda0) at
../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:479
#41 0x00006220 in main1 (argc=1, argv=0xbfffeb10, nativeApp=0x29d7b0) at
../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1273
#42 0x00006a30 in main (argc=1, argv=0xbfffeb10) at
../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1636
#43 0x00001c90 in _start ()
#44 0x00001ac0 in start ()
(gdb) q
The program is running.  Exit anyway? (y or n) y

Comment 1

[hacker formerly known as [e-mail]]

Upping severity and marking 1.3 blocker.

If I change the NS_ADDREF at nsJARChannel.cpp#69 to NS_IF_ADDREF, that just
changes the location of the crash:

(gdb) bt
#0  0x70004450 in szone_malloc ()
#1  0x700042b8 in malloc_zone_malloc ()
#2  0x700041f4 in malloc ()
#3  0x004a8f9c in JS_malloc (cx=0x20e43cb0, nbytes=58) at
../../../mozilla/js/src/jsapi.c:1424
#4  0x00556c04 in js_InflateString (cx=0x20e43cb0, bytes=0x1e030f4 "File Read
Error (underflow.)", length=28) at ../../../mozilla/js/src/jsstr.c:2782
#5  0x004b0d54 in JS_NewStringCopyZ (cx=0x20e43cb0, s=0x1e030f4 "File Read Error
(underflow.)") at ../../../mozilla/js/src/jsapi.c:3539
#6  0x01df6e0c in mozJSSubScriptLoader::LoadSubScript (this=0x20f5a910) at
../../../../../mozilla/js/src/xpconnect/loader/mozJSSubScriptLoader.cpp:295

Comment 2

[Darin Fisher]

-> my regression

Comment 3

[Darin Fisher]

the NS_IF_ADDREF patch seems important.  i think there is crash whenever someone
calls GetOwner or GetContentLength prior to OnStartRequest.  that needs to be fixed.

Comment 4

[Darin Fisher]

i'm updating my tree with --enable-calendar to try debugging this myself.

Comment 5

[Darin Fisher]

Attachment: stack trace w/ NS_IF_ADDREF patch

ok, with the NS_IF_ADDREF patch, i'm getting this stack trace.	if i just use
TestProtocols to load the document, then everything seems to be ok.  this seems
to be some heap corruption bug that is perhaps just ending up inside JS.  it
may not have anything to do with JS, or it might be a JS bug.  i'm not entirely
sure.

adding MALLOC_CHECK_=2 to the environment didn't catch any double frees.

Comment 6

[Darin Fisher]

Attachment: v0 patch

this patch includes the NS_IF_ADDREF change + some code to move the work of
extracting the "real size" attribute of the jar entry onto the same thread that
does the work of reading the jar entry.  that bit didn't seem to help any with
the crash, but it is probably still a good idea.

Comment 7

[Brant Gurganus]

Considering that this involves the calendar, adding calendar keyword.

Comment 8

[Mitch]

*** Bug 190762 has been marked as a duplicate of this bug. ***

Comment 9

[Darin Fisher]

Comment on attachment 112462 [details] [diff] [review]
v0 patch

this patch only fixes part of the crash, so i'd like to get it in.  the
remaining crash is likely a duplicate of or related to bug 190460.

Comment 10

[Doug Turner (:dougt)]

Comment on attachment 112462 [details] [diff] [review]
v0 patch

r=dougt

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 112462 [details] [diff] [review]
v0 patch

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 12

[Darin Fisher]

v0 patch checked in on trunk

Comment 13

[Darin Fisher]

crash/hang still exists with latest CVS trunk on linux.  not sure what's going on.

Comment 14

[Darin Fisher]

Attachment: second patch

ok, this patch fixes the final startup crash.  thanks to valgrind for helping
me locate the problem so quickly (something like 30 minutes after dbaron
suggested i try it!).

the problem was that for sync loads of jar channels, callers assume the jar
channel's GetContentLength method will not return -1.  the API says -1 is a
valid return value, but mozJSSubScriptLoader didn't seem to care.  it happily
allocated a buffer -1+1 bytes long and proceeded to fill it with data from the
jar stream :-)

the solution is to make sure nsJARChannel::GetContentLength will return the
correct content length when loading the jar channel synchronous (via
nsIChannel::Open).

Comment 15

[Doug Turner (:dougt)]

Comment on attachment 112923 [details] [diff] [review]
second patch

R=dOuGt

Comment 16

[Alec Flett]

Comment on attachment 112923 [details] [diff] [review]
second patch

sr=alecf

Comment 17

[Darin Fisher]

Comment on attachment 112923 [details] [diff] [review]
second patch

seeking drivers approval for 1.3 beta.	low-risk patch.  does the right thing
to fix this nasty crash ;-)

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 112923 [details] [diff] [review]
second patch

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 19

[Darin Fisher]

landed final patch

Comment 20

[hacker formerly known as [e-mail]]

Darin, does calendar work for you?  It doesn't crash when you pull up the
calendar window but my tasks, the month title, calendar lists and all of the
daily entries are blank.  I see this with both of my local win32 & osx builds.

Comment 21

[hacker formerly known as [e-mail]]

And the app crashes when you close the calendar window.

Comment 22

[Mike Potter]

The calendar crash is caused by the checkin of bug 176919 and the fact that it
broke the JSLIB library that is used to manage files (and the RDF data source of
multiple calendars).
http://bugzilla.mozdev.org/show_bug.cgi?id=2954 tracks that bug at MozDev, and I
talked to Pete Collins today who said he would try and get a look at it tomorrow.
The checkin to bug 176919 was pretty severe, since it broke a major library that
a lot of external app developers use.  I don't know how to avoid that in the
future, but if we can think of a way to do it, it will help the outside
development community.

Comment 23

[Darin Fisher]

mike: yeah, i was really shocked to learn about JSLIB!!  if i had only known
about it before landing this patch :(

it's very very dangerous depending on non-frozen gecko APIs!!  we should
probably file a bug to freeze the APIs used by JSLIB.  BTW: why isn't it part of
the tree if calendar depends on it?

Comment 24

[Mike Potter]

Its in the tree under mozilla/calendar/resources/content/jslib/ :)
Hopefully Pete will get JSLIB fixed up this morning, and all will be good again.

Comment 25

[Darin Fisher]

oh.. ic.. i figured since it is on mozdev.org that it wasn't part of the tree..
i guess this is just yet to happen since calendar is a fairly new addition to
the tree.  once again, sorry about the mess!