Closed Bug 591788 Opened 10 years ago Closed 10 years ago

Fatal assert ( base == lirbuf->sp || base == eos_ins)

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: bzbarsky, Assigned: njn)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

BUILD: Current tip JM and TM builds

STEPS TO REPRODUCE:
1)  Save attachment 470185 [details] (testcase for bug 591631) to ~/test.js
2)  Using a debug js shell, run |env TMFLAGS=stats js -j ~/test.js|

EXPECTED RESULTS: get some stats

ACTUAL RESULTS:
  Assertion failure: base == lirbuf->sp || base == eos_ins,
                     at ../jstracer.cpp:3797

In a debugger:

(gdb) p base
$1 = (nanojit::LIns *) 0x381f744
(gdb) p lirbuf->sp
$2 = (nanojit::LIns *) 0x825434
(gdb) p eos_ins
$3 = (nanojit::LIns * const) 0x825458
(gdb) p *base
$4 = {
  {
    sharedFields = {
      inReg = 0, 
      reg = nanojit::EAX, 
      inAr = 0, 
      isResultLive = 0, 
      arIndex = 0, 
      opcode = nanojit::LIR_addi
    }, 
    wholeWord = 0x4f000000
  }
}
(gdb) p *lirbuf->sp
$10 = {
  {
    sharedFields = {
      inReg = 0, 
      reg = nanojit::EAX, 
      inAr = 0, 
      isResultLive = 0, 
      arIndex = 0, 
      opcode = nanojit::LIR_ldi
    }, 
    wholeWord = 0x15000000
  }
}
(gdb) p *eos_ins
$11 = {
  {
    sharedFields = {
      inReg = 0, 
      reg = nanojit::EAX, 
      inAr = 0, 
      isResultLive = 0, 
      arIndex = 0, 
      opcode = nanojit::LIR_ldi
    }, 
    wholeWord = 0x15000000
  }
}

fwiw, looks like |x| is an sti opcode....
Blocks: 591631
blocking2.0: --- → ?
The jitstats bit isn't even needed.
Summary: Fatal assert ( base == lirbuf->sp || base == eos_ins) while trying to get jitstats → Fatal assert ( base == lirbuf->sp || base == eos_ins)
This is a repeat of bug 521190.  It's caused by a large stack/eos offset, so instead of ending up with something like this:

  sti.s sp[100000] = xyz

we end up with:

  addi1 = addi sp, 100000
  sti.s addi1[0] = xyz

but the assertion doesn't allow for that LIR pattern.

IIRC back then the maximum displacement for loads/stores on ARM was +/-4096, which was smaller than the other platforms.  I think that platform difference has now been hidden inside the back-ends, however there's now a +/-32768 maximum displacement for all platforms.  And this test is exceeding that by a small amount, it appears to be due to the large Float32 array -- if I reduce its size from 2048 to 1024 the assertion goes away.

The fix is simple, just apply the existing ARM-only code to all platforms.  I also made it slightly safer by not assuming the second operand of the add is an immediate, and using pointer sizes instead of integer sizes so it works on 64-bit platforms.
Assignee: general → nnethercote
Status: NEW → ASSIGNED
Attachment #470358 - Flags: review?(gal)
Attachment #470358 - Flags: review?(gal) → review+
http://hg.mozilla.org/mozilla-central/rev/0c31c6e5d26a
Status: ASSIGNED → RESOLVED
blocking2.0: ? → beta7+
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.