307529 - Crash [@ JS_CloneFunctionObject 3b0a6969]

Status: RESOLVED DUPLICATE of bug 434673

(Core :: XPConnect, defect)

Description

[Bob Clary [:bc] (inactive)]

Crashed during JavaScript Test Library browser test of Firefox 1.4/2005090805/Linux

I'm not sure of the actual test that cause this yet.

tb 9151693

JS_CloneFunctionObject() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsapi.c,
line 3250]
xpc_CloneJSFunction() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativeinfo.cpp,
line 56]
DefinePropertyIfFound() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 453]
XPC_WN_ModsAllowed_Proto_Resolve() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1606]
js_LookupPropertyWithFlags() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsobj.c,
line 2642]
js_LookupProperty() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsobj.c,
line 2500]
nsWindowSH::NewResolve() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 5786]
XPC_WN_Helper_NewResolve() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1022]
js_LookupPropertyWithFlags() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsobj.c,
line 2595]
js_LookupProperty() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsobj.c,
line 2500]
js_GetProperty() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsobj.c,
line 2784]
js_Interpret() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsinterp.c,
line 3287]
js_Execute() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsinterp.c,
line 1393]
JS_EvaluateUCScriptForPrincipals() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsapi.c,
line 3954]
nsJSContext::EvaluateString() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 146]
nsScriptLoader::EvaluateScript() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/content/base/src/nsScriptLoader.cpp,
line 704]
nsScriptLoader::ProcessRequest() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/content/base/src/nsScriptLoader.cpp,
line 660]
nsScriptLoader::OnStreamComplete() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/content/base/src/nsScriptLoader.cpp,
line 1024]
nsStreamLoader::OnStopRequest() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/base/src/nsStreamLoader.cpp,
line 712]
nsHttpChannel::OnStopRequest() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 1149]
nsInputStreamPump::OnStateStop() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 1149]
nsInputStreamPump::OnInputStreamReady() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 343]
nsInputStreamReadyEvent::EventHandler()
PL_HandleEvent() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/plevent.c,
line 689]
PL_ProcessPendingEvents() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/plevent.c,
line 623]
nsEventQueueImpl::ProcessPendingEvents() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/nsEventQueue.cpp,
line 423]
event_processor_callback() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 67]
libglib-2.0.so.0 + 0x47907 (0x0015b907)
libglib-2.0.so.0 + 0x2374b (0x0013774b)
libglib-2.0.so.0 + 0x251d2 (0x001391d2)
libglib-2.0.so.0 + 0x2547f (0x0013947f)
libgtk-x11-2.0.so.0 + 0x10a6a7 (0x040df6a7)
nsAppShell::Run() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 141]
nsAppStartup::Run() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
XRE_main() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/toolkit/xre/nsAppRunner.cpp,
line 2339]
main() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 62]
libc.so.6 + 0x14e23 (0x00b13e23)

Comment 1

[Bob Clary [:bc] (inactive)]

This only occured during the full run of the ecma*,js* browser based tests. It
did not appear in the individual tests.

Comment 2

[Brendan Eich [:brendan]]

Inferring a bit, it seems as though xpconnect must have failed to protect the
member (funval in DefinePropertyIfFound) before the AUTO_MARK_JSVAL executed.

/be

Comment 3

[Brendan Eich [:brendan]]

But I thought we had a marking protocol to protect members' values.  Hmm, maybe
if they are not Resolve'd, there's a window of vulnerability somewhere in Resolve?

/be

Comment 4

[Adam Guthrie]

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

Comment 5

[Adam Guthrie]

Attachment: testcase

testcase from OndraZizka

Comment 6

[Adam Guthrie]

Attachment: stacktrace from testcase

Right before I crash I also get: JavaScript error: http://ondra.zizka.cz/temp/sm_array_limit.html, line 15: out of memory

Comment 7

[Boris Zbarsky [:bzbarsky]]

This seems to work for me on trunk.  Are people still seeing this?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Though I do see this end up in some sort of very long loop in MarkGCThing walking a seemingly neverending sprop parent chain...

Comment 9

[Brendan Eich [:brendan]]

(In reply to comment #8)
> Though I do see this end up in some sort of very long loop in MarkGCThing
> walking a seemingly neverending sprop parent chain...

300 links long?  The testcase builds an array via push, and until bug 322889 is fixed, that means a path in the JSRuntime's property tree of height 300.

Who can still reproduce the crash with today's trunk build?

/be

Comment 10

[Boris Zbarsky [:bzbarsky]]

> 300 links long?

Could be... long enough it effectively hung my build.

Comment 11

[Brendan Eich [:brendan]]

A loop over a linked list 300 elements is not going to hang anything.  Maybe
the parent chain was corrupted and there's an iloop?  Can you get more data
from gdb?

/be

Comment 12

[Boris Zbarsky [:bzbarsky]]

It's not a complete hang.  Just takes longer and longer to run GC, as far as I can tell.  I'm at what looks like the 4th GC run, and it's taking at least 40 seconds so far (on a dual P4 3.6 GHz, but in a debug build).  The numbers the testcase is showing are in the 100000 range or so.

In an opt trunk build on much slower hardware I don't see a crash or a hang... until I get up to 430000 or so.  At that point, CPU usage drops to 0.  The browser "responds", except that no menus can be opened (just get a tiny menu with no options), no keyboard shortcuts work, and the [x] in the title bar doesn't work.  Oh, and typing in the URL bar doesn't work either.  Killing the browser via kill or deleting its X window does work.

Comment 13

[Mike Shaver (:shaver emeritus)]

Bug 434673?

Comment 14

[Johnny Stenback (:jst)]

I bet, duping...