Closed Bug 614510 Opened 9 years ago Closed 9 years ago

Assertion failure: frame entry NNN wasn't freed

Categories

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect, P1)

x86_64
Linux
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 609028
flash10.2.x-Spicy

People

(Reporter: jstpierre, Unassigned)

References

Details

Attachments

(1 file)

1.28 KB, application/octet-stream
Details
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
Attached file ABC file
It's a nanojit bug: when running with -Dinterp, it works.
Priority: -- → P1
Target Milestone: --- → flash10.2.x-Spicy
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
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 609028
bulk verifying resolved !fixed issues
Status: RESOLVED → VERIFIED
Depends on: 607816
You need to log in before you can comment on or make changes to this bug.