On current tip (42063595d186): harmony-jacob-0:~/moz/tm.d$ ./js -m /work/moz/mozilla.org/tracemonkey/js/src/jit-test/tests/basic/bug489098.js Assertion failure: offset, at /work/moz/tm/js/src/methodjit/MonoIC.cpp:253 Aborted The fault is here: ---- [ MonoIC.cpp line 187 ] ---- Label start = masm.label(); DataLabel32 shapeLabel; Jump guard = masm.branch32WithPatch(Assembler::NotEqual, ic->shapeReg, Imm32(obj->shape()), shapeLabel); ---- [ MonoIC.cpp line 250 ] ---- int offset = linker.locationOf(shapeLabel) - linker.locationOf(start); ic->extraShapeGuard = offset; JS_ASSERT(ic->extraShapeGuard == offset); JS_ASSERT(offset); ---- On ARM, branch32WithPatch can put shapeLabel at the start of the instruction sequence, so 'offset' can be zero (and this is correct). On the face of it, it looks like I can just strip out the assertion. However, the assertion (and much of this code) was added as part of bug 627486, and I'm not on the access list for it so I'm not sure what it's about. Can this assertion (and others like it) just be stripped?
Summary: ARM breakage: ASSERT(offset) when 0 is a valid offset. → ASSERT(offset) when 0 is a valid offset on ARM.
Ok, disabling the offending assertion on current tip (9ecbccbaff7b) causes the engine to enter an infinite loop. Something is wrong here.
I verified that 410fe81fff16 triggers both the assertion failure and the infinite loop (though the loop is hidden by the failing assertion). The problem is related to setgname, and the infinite loop doesn't appear to leave JIT-compiled code. I'm not certain what's causing it, but I suspect one of the linkJumps is linking to the wrong place.
tracking-fennec: --- → ?
According to cdleary (on IRC), this was independently fixed by dvander shortly after I filed this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.