1591019 - Assertion failure: adjustedExponent >= mozilla::FloorLog2(mozilla::Abs(upper_)), at js/src/jit/RangeAnalysis.h:240

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision ad7a152bc66c (build with --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off --ion-warmup-threshold=0 --baseline-eager --ion-gvn=off):

"foo".charAt(3.4);
for (name of []) {}

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  js::jit::Range::assertInvariants (this=this@entry=0x7ffff5fa51e0) at js/src/jit/RangeAnalysis.h:240
#1  0x000055555653b658 in js::jit::Range::refineToExcludeNegativeZero (this=0x7ffff5fa51e0) at js/src/jit/RangeAnalysis.h:589
#2  js::jit::Range::toIntegerInt32 (alloc=..., op=op@entry=0x7fffffffbef0) at js/src/jit/RangeAnalysis.cpp:1220
#3  0x000055555653d2a2 in js::jit::MToIntegerInt32::computeRange (this=0x7ffff5f9b3e8, alloc=...) at js/src/jit/RangeAnalysis.cpp:1727
#4  0x000055555655e973 in js::jit::RangeAnalysis::analyze (this=this@entry=0x7fffffffc030) at js/src/jit/RangeAnalysis.cpp:2367
#5  0x000055555645fcd0 in js::jit::OptimizeMIR (mir=mir@entry=0x7ffff5f9a300) at js/src/jit/Ion.cpp:1301
#6  0x000055555646085d in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff5f9a300) at js/src/jit/Ion.cpp:1628
#7  0x00005555564617b1 in js::jit::IonCompile (cx=<optimized out>, cx@entry=0x7ffff5f27000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x7fffffffc6e8, baselineFrameSize=baselineFrameSize@entry=96, osrPc=osrPc@entry=0x7ffff4cc2dac "\343\024", recompile=<optimized out>, optimizationLevel=js::jit::OptimizationLevel::Normal) at js/src/jit/Ion.cpp:1923
#8  0x0000555556462126 in js::jit::Compile (cx=cx@entry=0x7ffff5f27000, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffc6e8, osrFrameSize=osrFrameSize@entry=96, osrPc=osrPc@entry=0x7ffff4cc2dac "\343\024", forceRecompile=<optimized out>) at js/src/jit/Ion.cpp:2139
#9  0x0000555556462b9c in BaselineCanEnterAtBranch (pc=0x7ffff4cc2dac "\343\024", osrFrameSize=96, osrFrame=0x7fffffffc6e8, script=..., cx=0x7ffff5f27000) at js/src/jit/Ion.cpp:2335
#10 IonCompileScriptForBaseline (cx=<optimized out>, frame=frame@entry=0x7fffffffc6e8, frameSize=frameSize@entry=96, pc=pc@entry=0x7ffff4cc2dac "\343\024") at js/src/jit/Ion.cpp:2390
#11 0x0000555556462fd7 in js::jit::IonCompileScriptForBaselineOSR (cx=<optimized out>, frame=0x7fffffffc6e8, frameSize=96, pc=0x7ffff4cc2dac "\343\024", infoPtr=0x7fffffffc698) at js/src/jit/Ion.cpp:2519
#12 0x0000364f7e425ee7 in ?? ()
#13 0x00007fffffffc728 in ?? ()
#14 0x00007fffffffc698 in ?? ()
#15 0x00007ffff4dea148 in ?? ()
#16 0x0000000000000000 in ?? ()
rax	0x555558071fa0	93825037442976
rbx	0x7ffff5fa51e0	140737320210912
rcx	0x555556f5ece0	93825019538656
rdx	0x0	0
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7fffffffbe90	140737488338576
rsp	0x7fffffffbe90	140737488338576
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff7fe6cc0	140737354034368
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x7fffffffbef0	140737488338672
r13	0x7ffff5f9a020	140737320165408
r14	0x7ffff5f9a710	140737320167184
r15	0x7ffff4cdb6d0	140737300510416
rip	0x555556563aa9 <js::jit::Range::assertInvariants() const+409>
=> 0x555556563aa9 <js::jit::Range::assertInvariants() const+409>:	movl   $0x0,0x0
   0x555556563ab4 <js::jit::Range::assertInvariants() const+420>:	ud2

All the tests I have seen so far require --ion-gvn=off but it is possible that a more complicated testcase could get away without that. Hence marking s-s because this is a range analysis problem.

Comment 1

[Jan de Mooij [:jandem]]

André, I assume this is from your changes?

Comment 2

[André Bargull [:anba]]

Attachment: Bug 1591019: Adjust max-exponent when excluding fractional parts in range analysis. r=jandem!

Range::max_exponent_ must be adjusted when Range::canHaveFractionalPart_ is
changed to ExcludesFractionalParts, cf. Range::floor and Range::ceil. Since
the range analysis semantics for Range::toIntegerInt32 matches the one in
Range::ceil, we can simply call Range::ceil in Range::toIntegerInt32.
Furthermore as the last steps in Range::toIntegerInt32 are the same as in
Range::NaNToZero, we can simplify Range::toIntegerInt32 to just call
Range::NaNToZero(Range::ceil(range)).

Comment 3

[André Bargull [:anba]]

(In reply to Jan de Mooij [:jandem] from comment #1)

André, I assume this is from your changes?

Yes. Thankfully it seems to be easy to fix.

Comment 4

[Daniel Veditz [:dveditz]]

Please add the regressing bug link.

Comment 5

[André Bargull [:anba]]

(In reply to Daniel Veditz [:dveditz] from comment #4)

Please add the regressing bug link.

bug 1383436

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/45c6d9f6548e2744e4f673afe1737eb6beda0ce5

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/45c6d9f6548e

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to André Bargull [:anba] from comment #5)

bug 1383436

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/d9d678e7422e
user: André Bargull
date: Tue Oct 22 09:37:38 2019 +0000
summary: Bug 1383436 - Part 10: Use MToIntegerInt32 when inlining charAt and charCodeAt. r=jandem

Confirmed!