Assertion failure: offset_ == offset, at jit/Label.h

RESOLVED INVALID

Status

()

Core
JavaScript Engine: JIT
--
critical
RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: gkw, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
ARM
Linux
assertion, regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8460111 [details]
stack

function f(code) {
    return {
        c: code.replace(/\s/, "")
    }
}
f("")

asserts js debug shell on m-c changeset 9fdb8047f07d with --arm-asm-nop-fill=103859781 --no-baseline --ion-offthread-compile=off --ion-eager at Assertion failure: offset_ == offset, at jit/Label.h

This takes about 6 minutes to crash on my ARM board.

My configure flags are:

CC="gcc-4.7 -mfloat-abi=softfp -B/usr/lib/gcc/arm-linux-gnueabi/4.7" CXX="g++-4.7 -mfloat-abi=softfp -B/usr/lib/gcc/arm-linux-gnueabi/4.7" AR=ar sh /home/fuzz5lin/trees/mozilla-central/js/src/configure --target=arm-linux-gnueabi --enable-debug --enable-optimize --enable-gczeal --enable-debug-symbols --disable-tests --enable-more-deterministic --with-ccache --enable-threadsafe

Douglas, this is an issue that seems to involve --arm-asm-nop-fill=103859781, or is this an issue with irregexp?
Flags: needinfo?(dtc-moz)
(Reporter)

Comment 1

4 years ago
Prior to reduction, I may have seen the following assert too:

Assertion failure: this->nodeSize_ < SliceSize, at jit/shared/IonAssemblerBufferWithConstantPools.h
(In reply to Gary Kwong [:gkw] [:nth10sd] PTO Jul 19 to 27 from comment #0)
> Created attachment 8460111 [details]
> stack
> 
> function f(code) {
>     return {
>         c: code.replace(/\s/, "")
>     }
> }
> f("")
> 
> asserts js debug shell on m-c changeset 9fdb8047f07d with
> --arm-asm-nop-fill=103859781 --no-baseline --ion-offthread-compile=off
> --ion-eager at Assertion failure: offset_ == offset, at jit/Label.h
> 
> This takes about 6 minutes to crash on my ARM board.
> 
> My configure flags are:
> 
> CC="gcc-4.7 -mfloat-abi=softfp -B/usr/lib/gcc/arm-linux-gnueabi/4.7"
> CXX="g++-4.7 -mfloat-abi=softfp -B/usr/lib/gcc/arm-linux-gnueabi/4.7" AR=ar
> sh /home/fuzz5lin/trees/mozilla-central/js/src/configure
> --target=arm-linux-gnueabi --enable-debug --enable-optimize --enable-gczeal
> --enable-debug-symbols --disable-tests --enable-more-deterministic
> --with-ccache --enable-threadsafe
> 
> Douglas, this is an issue that seems to involve
> --arm-asm-nop-fill=103859781, or is this an issue with irregexp?

Such a large nop-fill just blows the code size limits. The above attempts to fill almost 400MB of code. This should be handled better but the working code size limit is currently only 32MB. Could you limit the nop-fill testing range to 0 - 4096, and even 0 - 1 would be a good starting point. We need to explore the code size limits too, but it seems more important to verify the practical code size limits for now.
Flags: needinfo?(dtc-moz)

Updated

4 years ago
Flags: needinfo?(gary)
(Reporter)

Comment 3

4 years ago
(In reply to Douglas Crosher [:dougc] from comment #2)
> Such a large nop-fill just blows the code size limits. The above attempts to
> fill almost 400MB of code. This should be handled better but the working
> code size limit is currently only 32MB. Could you limit the nop-fill testing
> range to 0 - 4096, and even 0 - 1 would be a good starting point.

In fuzzing rev 6fea320ea6b1, I limited this to 4096, and will file new bugs for issues that show up with this new limit.

In the meantime, this can probably be resolved INVALID.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(gary)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.