User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101123 Firefox-4.0/4.0b8pre Build Identifier: When running the ABC attached, I get an assertion failure: Assertion failure: frame entry 160 wasn't freed : _entries[i] == __null (/home/jstpierre/Source/tamarin-redux/nanojit/Assembler.cpp:2322) Trace/breakpoint trap Reproducible: Always

It's a nanojit bug: when running with -Dinterp, it works.

The patches of bug 607816 fix this issue, so it appears to be the same root cause. But double checking prior to marking this a dup.

# The following snip-it highlights the issue and was generated by # running a debug debugger version of tamarin with following # flags: -Dverbose=verify,jit,raw,regs # # NOTE due to 'raw' option the code is displayed in reverse order. # i.e. instructions are displayed from physically higher addresses # to lower addresses. # # Looking at the trace below notice how csn is used in B52 (i.e. parameter of callv) # and since control flow from the prior block appears to fall into B52, the # allocator is restoring it along that edge; i.e. lea ecx,-236(ebp) <= restore csn # # This is incorrect since the call to throwAtom from the prior block never # returns and thus there is no fall-through path into B52 or put another # way; we shouldn't have love from that shack. # debugExit1 = callv.all #debugExit ( parami1 csn ) AR 4-144(vars) 148-164(tags) 172-180(methodFrame) 188-236(csn) RR eax(parami1) ecx(csn) 0x... movq -80(ebp),xmm0 std.v vars[64] = i2d1 AR 4-144(vars) 148-164(tags) 172-180(methodFrame) 188-236(csn) RR eax(parami1) ecx(csn) xmm0(i2d1) 0x... cvtsi2sd xmm0,edx 0x... xorpd xmm0,xmm0 i2d1 = i2d icalli2 AR 4-144(vars) 148-164(tags) 172-180(methodFrame) 188-236(csn) RR eax(parami1) ecx(csn) edx(icalli2) 0x... [B52] B52: AR 4-144(vars) 148-164(tags) 172-180(methodFrame) 188-236(csn) RR eax(parami1) ecx(csn) edx(icalli2) 0x... lea ecx,-236(ebp) <= restore csn 0x... mov ebx,-168(ebp) <= restore ebx 0x... mov edx,ebx 0x... mov esi,-184(ebp) <= restore esi 0x... mov eax,esi 0x... add esp,16 0x... call throwAtom 0x... push ...

Marking as duplicate of bug 609028

bulk verifying resolved !fixed issues