Closed Bug 616170 Opened 15 years ago Closed 15 years ago

Assertion failure: found js::analyze::Bytecode::mergeDefines

Categories

(Core :: JavaScript Engine, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: bc, Assigned: bhackett1024)

References

(
URL
)

Details

(Keywords: assertion, reproducible, testcase, Whiteboard: fixed-in-tracemonkey)

Attachments

(3 files)

testcase
207 bytes, text/html
Details
js that reproduces the bug
36.26 KB, application/javascript
Details
patch
1.42 KB, patch
dvander
: review+
Details | Diff | Splinter Review
1. http://abc.go.com/shows/greys-anatomy 2. Assertion failure: found, at c:/work/mozilla/builds/2.0.0/mozilla/js/src/jsanalyze.cpp:118 so far winxp/win7 Thread 0 (crashed) 0 mozjs.dll!JS_Assert [jsutil.cpp : 73 + 0x0] eip = 0x007f01ba esp = 0x00129580 ebp = 0x00129580 ebx = 0x054c0048 esi = 0x076f2870 edi = 0x076f2870 eax = 0xffffffff ecx = 0xdb1c8298 edx = 0x00613d38 efl = 0x00210212 Found by: given as instruction pointer in context 1 mozjs.dll!js::analyze::Bytecode::mergeDefines(JSContext *,js::analyze::Script *,bool,unsigned int,unsigned int *,unsigned int) [jsanalyze.cpp : 118 + 0x1a] eip = 0x0064934d esp = 0x00129588 ebp = 0x001295bc Found by: call frame info 2 mozjs.dll!js::analyze::Script::addJump(JSContext *,unsigned int,unsigned int *,unsigned int *,unsigned int,unsigned int *,unsigned int) [jsanalyze.cpp : 177 + 0x21] eip = 0x0064aab5 esp = 0x001295c4 ebp = 0x001295e8 Found by: call frame info 3 mozjs.dll!js::analyze::Script::analyze(JSContext *,JSScript *) [jsanalyze.cpp : 645 + 0x2c] eip = 0x0064a08c esp = 0x001295f0 ebp = 0x001296d4 Found by: call frame info 4 mozjs.dll!js::mjit::Compiler::performCompilation(js::mjit::JITScript * *) [Compiler.cpp : 166 + 0x1a] eip = 0x008a3b3d esp = 0x001296dc ebp = 0x00129778 Found by: call frame info 5 mozjs.dll!js::mjit::Compiler::compile() [Compiler.cpp : 134 + 0xb] eip = 0x008a3a39 esp = 0x00129780 ebp = 0x001297a0 Found by: call frame info 6 mozjs.dll!js::mjit::TryCompile(JSContext *,JSStackFrame *) [Compiler.cpp : 245 + 0xa] eip = 0x008a445f esp = 0x001297a8 ebp = 0x0012d1b0 Found by: call frame info 7 mozjs.dll!UncachedInlineCall [InvokeHelpers.cpp : 387 + 0xc] eip = 0x008fc6e0 esp = 0x0012d1b8 ebp = 0x0012d1e4 Found by: call frame info 8 mozjs.dll!js::mjit::stubs::UncachedCallHelper(js::VMFrame &,unsigned int,js::mjit::stubs::UncachedCallResult *) [InvokeHelpers.cpp : 485 + 0x15] eip = 0x008fca64 esp = 0x0012d1ec ebp = 0x0012d20c Found by: call frame info 9 mozjs.dll!CallCompiler::update() [MonoIC.cpp : 831 + 0x25] eip = 0x008e9e2c esp = 0x0012d214 ebp = 0x0012d244 Found by: call frame info 10 mozjs.dll!js::mjit::ic::Call(js::VMFrame &,js::mjit::ic::CallICInfo *) [MonoIC.cpp : 884 + 0x7] eip = 0x008e9d56 esp = 0x0012d24c ebp = 0x0012d264 Found by: call frame info 11 mozjs.dll!js::mjit::EnterMethodJIT(JSContext *,JSStackFrame *,void *,js::Value *) [MethodJIT.cpp : 745 + 0x14] eip = 0x00893e6d esp = 0x0012d2ac ebp = 0x0012d2a4 Found by: call frame info with scanning
Summary: Assertion failure: found Assertion failure: found js::analyze::Bytecode::mergeDefines → Assertion failure: found js::analyze::Bytecode::mergeDefines
+Linux
OS: Windows XP → All
blocking2.0: --- → ?
This page crashed on me the first time, but if I try again it works fine, even after clearing cookies or starting private browsing. Do you get this behavior? Is there a way to get this to crash consistently?
The assertion fires reliably for me on Windows. Maybe try a new profile? Brian, you are using a debug build?
Assignee: general → bhackett1024
I checked this in a debug build from today's tm tip and didn't get anything? Bob, can you still reproduce?
blocking2.0: ? → betaN+
This assertion almost certainly still exists, but I'm still not able to repro. If someone does get it to repro, can you post the disassembly of this->script in the Script::analyze frame, and the arguments to addJump? For 2.0, this is a correctness assertion about information which is currently only used when the tracer is disabled. The type inference uses it, and if bug 604541 gets fixed it will always be used.
I have a list of 22 urls where I have seen this assert. I'm retesting them now on winxp but in the meantime this one just reproduced on winxp: http://www.abc.es/20101029/tecnologia/firefox-retrasa-hasta-principios-201010291328.html
I was able to reproduce on Linux with: <http://www.abc.es/20101029/tecnologia/firefox-retrasa-hasta-principios-201010291328.html> 3 out of 5 times. <http://www.tomshardware.com> 3 out of 5 times (2 of those on x86_64). <http://www.treehugger.com/files/2009/12/powering-home-by-bike.php> 2 out of 5 times. And WinXP with: <http://www.abc.es/20101029/tecnologia/firefox-retrasa-hasta-principios-201010291328.html> 3 out of 3 times. Note that Firefox exited normally but I still saw the assertion and got a minidump. <http://www.treehugger.com/files/2009/12/powering-home-by-bike.php> 2 out of 3 times. Once Firefox exited normally and the other two times it had an abnormal exit. I could not reproduce on Mac OS X 10.5 intel.
blocking2.0: betaN+ → -
status2.0: --- → wanted
I can't reproduce this, m-c nightly rev 210237f7d626.
dvander: you tried a nightly? This is a debug only assertion. Which OS did you use?
Whoops, sorry, for some reason I thought it would crash. I'll test again with a debug build.
I can't reproduce this on a debug build either, tm rev abd854c5d634, --disable-optimize --enable-debug --disable-crashreporter --disable-jemalloc
dvander: which os? It didn't reproduce at all on Mac. It also didn't reproduce 100% of the time for me.
Attached file testcase —
Thanks! Unfortunately I'm away this month and next, so can't look at this. dvander, do you mind taking a look? The problem may be that when processing a backedge in the 'while' loop we think 't' is not defined, when it actually is (in that case the assertion would be bogus).
dvander, can you take this? It is a frequent assert in my crash testing.
I've seen this now on over 140 urls.
Assignee: bhackett1024 → danderson
from www.foxnews.com today - the attached js was at http://cdn.eyewonder.com/100125/767494/1422017/exp_Proxy.js and reliably asserts for me: Assertion failure: found, at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/jsanalyze.cpp:118 Program received signal SIGABRT, Aborted. 0x00007ffff7bcea0b in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 42 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/pt-raise.c (gdb) bt #0 0x00007ffff7bcea0b in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 #1 0x00007ffff661d714 in JS_Assert (s=0x7ffff6f98ee3 "found", file=0x7ffff6f98e88 "/home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/jsanalyze.cpp", ln=118) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/jsutil.cpp:83 #2 0x00007ffff6786b1c in js::analyze::Bytecode::mergeDefines (this=0x7fffd7134c00, cx=0x7fffd9e19400, script=0x7fffffff8b10, initial=false, newDepth=0, newArray=0x0, newCount=0) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/jsanalyze.cpp:118 #3 0x00007ffff67880e3 in js::analyze::Script::addJump (this=0x7fffffff8b10, cx=0x7fffd9e19400, offset=38, currentOffset=0x7fffffff8ab4, forwardJump=0x7fffffff8ac0, stackDepth=0, defineArray=0x0, defineCount=0) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/jsanalyze.cpp:177 #4 0x00007ffff6787cc3 in js::analyze::Script::analyze (this=0x7fffffff8b10, cx=0x7fffd9e19400, script=0x7fffdd5c6b80) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/jsanalyze.cpp:645 #5 0x00007ffff66d24bf in js::mjit::Compiler::performCompilation (this=0x7fffffff8c20, jitp=0x7fffdd5c6c20) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/Compiler.cpp:171 #6 0x00007ffff66d23dc in js::mjit::Compiler::compile (this=0x7fffffff8c20) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/Compiler.cpp:136 #7 0x00007ffff66d2d8a in js::mjit::TryCompile (cx=0x7fffd9e19400, fp=0x7fffe23fe0c8) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/Compiler.cpp:256 #8 0x00007ffff6735f7d in UncachedInlineCall (f=..., flags=0, pret=0x7fffffffcf10, argc=0) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/InvokeHelpers.cpp:383 #9 0x00007ffff67363ba in js::mjit::stubs::UncachedCallHelper (f=..., argc=0, ucr=0x7fffffffcf00) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/InvokeHelpers.cpp:473 #10 0x00007ffff671d9fa in CallCompiler::update (this=0x7fffffffcf70) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/MonoIC.cpp:807 #11 0x00007ffff6719443 in js::mjit::ic::Call (f=..., ic=0x7fffd4232190) at /home/mcmanus/src/mozilla2/wd/632061-09failure/js/src/methodjit/MonoIC.cpp:860 #12 0x00007fffdfd1abf1 in ?? () #13 0x00007fffdfd19dd8 in ?? () #14 0x0000000000000000 in ?? ()
Assignee: dvander → bhackett1024
Attached patch patch — — Splinter Review
This assert is bogus, if a variable became unconditionally defined at the head of a loop we would trip while asserting it was defined along all backedges. This patch cleans up the defined-variables state to avoid the assert.
Attachment #516775 - Flags: review?(dvander)
Attachment #516775 - Flags: review?(dvander) → review+
http://hg.mozilla.org/tracemonkey/rev/4ea63230456d
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/4ea63230456d
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
yay! I'll retest this tomorrow.
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug616170.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: