Closed Bug 628170 Opened 15 years ago Closed 15 years ago

CPython-compiled-to-JavaScript demo crashes

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 625141
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: azakai, Assigned: dvander)

References

(
URL
)

Details

(Keywords: crash, regression, Whiteboard: hardblocker)

http://syntensity.com/static/python.html is a demo of CPython compiled to JavaScript (using Emscripten). It worked well until recently. mozilla-central nightly of Jan 7 is ok. (ditto previous builds) mozilla-central nightly of Jan 8 is bad. (ditto later builds) In the ok build, the page loads in a few seconds. Whereas in the bad build, it stays at 100% CPU for a long time (probably 10x more, need to say 'continue' when asked if to stop the script), takes over 1GB of RAM (in the ok build, hardly any additional memory is taken), and finally does not complete the load, instead reporting an erroneous error in the script (which does not occur in the ok build, or on other browsers). The erroneous error is perhaps not useful, but in any case, Error: uncaught exception: Invalid element in slab at u([object Array],4,1)@http://syntensity.com/static/python.js:8 lU(52428968,1065188,1065192)@http://syntensity.com/static/python.js:2797 zcc(52428968)@http://syntensity.com/static/python.js:2796 PS(52428968)@http://syntensity.com/static/python.js:2797 XZ(1124248,1065164)@http://syntensity.com/static/python.js:2781 N(1136032,1124248,1065164)@http://syntensity.com/static/python.js:1161 OT(1290980,3893)@http://syntensity.com/static/python.js:1160 SU(1065156,0)@http://syntensity.com/static/python.js:2933 XZ(52,1065144)@http://syntensity.com/static/python.js:2785 N(1126352,52,1065144)@http://syntensity.com/static/python.js:1161 $O(52,2682,4376)@http://syntensity.com/static/python.js:86 r0b(4376)@http://syntensity.com/static/python.js:1458 Z0(0)@http://syntensity.com/static/python.js:1466 x0b()@http://syntensity.com/static/python.js:1468 b1(1511824)@http://syntensity.com/static/python.js:1478 mZ(1109848,0)@http://syntensity.com/static/python.js:3198 lZ(1109848,1107468,1342040)@http://syntensity.com/static/python.js:1033 BVb(1107468,1345296,1638)@http://syntensity.com/static/python.js:1034 hic(1107468)@http://syntensity.com/static/python.js:3384 cX(1107468)@http://syntensity.com/static/python.js:3302 O6b()@http://syntensity.com/static/python.js:2071 v$b(1)@http://syntensity.com/static/python.js:2457 F0()@http://syntensity.com/static/python.js:2461 t3(4,1409192)@http://syntensity.com/static/python.js:1896 ([object Array])@http://syntensity.com/static/python.js:6245 doRun()@http://syntensity.com/static/python.html:56 onload([object Event])@http://syntensity.com/static/python.html:1
I forgot to say, in a bad build, after the erroneous error happens, pressing reload will crash the browser. Here is a report: http://crash-stats.mozilla.com/report/index/bp-6b410c23-21af-48e5-9dcf-8e1562110123 stack trace from there: 0 @0x283dfb2 1 libxul.so js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:748 2 libxul.so js::Invoke js/src/jsinterp.cpp:654 3 libxul.so js::ExternalInvoke js/src/jsinterp.cpp:858 4 libxul.so JS_CallFunctionValue js/src/jsinterp.h:961 5 libxul.so nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2005 6 libxul.so nsJSEventListener::HandleEvent dom/src/events/nsJSEventListener.cpp:228 7 @0xa1f7e77f 8 libxul.so nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1114 9 @0xa1f7e77f 10 libxul.so nsEventListenerManager::HandleEventInternal content/events/src/nsEventListenerManager.cpp:1209 11 libxul.so nsEventTargetChainItem::HandleEvent content/events/src/nsEventListenerManager.h:146 12 libxul.so nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:341 13 libxul.so nsEventDispatcher::Dispatch content/events/src/nsEventDispatcher.cpp:628 14 libxul.so DocumentViewerImpl::LoadComplete layout/base/nsDocumentViewer.cpp:1046 15 libxul.so nsDocShell::EndPageLoad docshell/base/nsDocShell.cpp:6070 16 libxul.so nsDocShell::OnStateChange docshell/base/nsDocShell.cpp:5924 17 libxul.so nsDocLoader::FireOnStateChange uriloader/base/nsDocLoader.cpp:1334 18 libxul.so nsDocLoader::doStopDocumentLoad uriloader/base/nsDocLoader.cpp:942 19 libxul.so nsDocLoader::DocLoaderIsEmpty uriloader/base/nsDocLoader.cpp:818 20 libxul.so nsDocLoader::OnStopRequest uriloader/base/nsDocLoader.cpp:702 21 libxul.so nsLoadGroup::RemoveRequest netwerk/base/src/nsLoadGroup.cpp:680 22 libxul.so nsDocument::DoUnblockOnload content/base/src/nsDocument.cpp:7275 23 @0xae40c4bf 24 @0xb2d553d3 25 libxul.so NS_ProcessNextEvent_P nsThreadUtils.cpp:250 26 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:110 27 libxul.so MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 28 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:202 29 libxul.so nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:195 30 libxul.so nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:217 31 @0x24951af 32 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp:3773 33 firefox-bin main nsBrowserApp.cpp:158 34 libc-2.12.1.so libc-2.12.1.so@0x16ce6 35 firefox-bin firefox-bin@0x1390 36 firefox-bin Output nsBrowserApp.cpp:77 37 @0x0 Other reports: http://crash-stats.mozilla.com/report/pending/cb5e1fad-8c7b-41b7-b7e0-b3faa2110123 http://crash-stats.mozilla.com/report/pending/e54fee87-00cf-40e3-98f0-3b7532110123
Alon, what are the build ids of those builds? And if those are m-c builds, can you look into the regression range on tm?
blocking2.0: --- → ?
Keywords: regression
Builds are mozilla-central nightlies. IDs: Good build: Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre Bad build: Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre I will try to find a regression range for tracemonkey.
Ok, for tracemonkey nightly builds: Jan 5 is ok Jan 6 has the problem mentioned above I am not certain exactly what changesets the nightly builds correspond to (is there an easy way to see that, btw?). Here is a (slightly too big) range: http://hg.mozilla.org/tracemonkey/pushloghtml?startdate=1%2F3%2F11&enddate=1%2F6%2F11 I will try to narrow it down tomorrow to a single changset.
> I am not certain exactly what changesets the nightly builds correspond to See about:buildconfig
Blocks: WebJSPerf
blocking2.0: ? → .x
Ok, bisection shows the regression is in http://hg.mozilla.org/tracemonkey/rev/5bb0f4c62370 which is bug 594247. bz: thanks for the about:buildconfig tip, very useful.
blocking2.0: .x → ?
Depends on: 594247
So this is producing incorrect behavior, not just slowness, right?
Blocks: 594247
No longer depends on: 594247
Absolutely. Reproducible crash on my Mac OS X 10.6.6
Crashes with beta 9 on OS X, but does not crash with latest tracemonkey nightly. I do get a "too much recursion" error in the Web Console (and when I load python.js in the shell).
(In reply to comment #8) > So this is producing incorrect behavior, not just slowness, right? Yes, I can reproduce a crash 100% of the time on reload of the page on Ubuntu 10.10 (links to crash reports are in comment 1). The first load of the page encounters excessive memory usage and the page fails to load due to an error (that should not happen). Looks like crashes on first load happen on OS X (last few comments). With JITs disabled, the problem does not happen, which makes sense since the patch that is responsible for the regression deals with typed arrays in the method JIT (see comment 6).
Assignee: general → danderson
Morphed to cover the crash, which blocks. If the perf regression still applies, and is a separate bug, please file a new one on that.
Status: NEW → ASSIGNED
blocking2.0: ? → betaN+
Keywords: crash
Summary: CPython-compiled-to-JavaScript demo regressed on Jan 8 2011 → CPython-compiled-to-JavaScript demo crashes
Whiteboard: hardblocker
This looks like bug 625141. I verified locally that Paul's patch fixes it.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
How's perf with Paul's excellent fix? /be
(In reply to comment #16) > How's perf with Paul's excellent fix? > > /be I compared a build from before the regression, to current tracemonkey+patch for 625141, on a simple benchmark. It's 25-30% faster, very nice!
You need to log in before you can comment on or make changes to this bug.