1463375 - Assertion failure: location == ChunkLocation::Nursery || location == ChunkLocation::TenuredHeap, at dist/include/js/HeapAPI.h:480

Reporter

Description

•

6 years ago

The following testcase crashes on mozilla-central revision dc1868d255be (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize --enable-simulator=arm64, run with --fuzzing-safe):

var N = 20 * 1000;
var a = new Array(N);
function f(x) {
    f.apply(null, arguments);
}
f.apply(null, a);


Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x0000000000478404 in js::gc::IsInsideNursery (cell=<optimized out>) at dist/include/js/HeapAPI.h:480
#1  0x000000000090d651 in js::gc::Cell::isTenured (this=0x7ffff492f040) at js/src/gc/Cell.h:55
#2  js::gc::Cell::asTenured (this=0x7ffff492f040) at js/src/gc/Cell.h:193
#3  0x0000000000f7dcd6 in js::gc::GCRuntime::checkIncrementalZoneState<JSFatInlineString> (t=0x7ffff492f040, cx=0x7ffff5f17000) at js/src/gc/Allocator.cpp:341
#4  js::gc::GCRuntime::tryNewTenuredThing<JSFatInlineString, (js::AllowGC)1> (cx=0x7ffff5f17000, kind=kind@entry=js::gc::AllocKind::FAT_INLINE_STRING, thingSize=thingSize@entry=32) at js/src/gc/Allocator.cpp:263
#5  0x0000000000f7e3ff in js::AllocateString<JSFatInlineString, (js::AllowGC)1> (cx=<optimized out>, heap=heap@entry=js::gc::DefaultHeap) at js/src/gc/Allocator.cpp:200
#6  0x0000000000cbd174 in js::Allocate<JSFatInlineString, (js::AllowGC)1> (heap=js::gc::DefaultHeap, cx=<optimized out>) at js/src/gc/Allocator.h:57
#7  JSFatInlineString::new_<(js::AllowGC)1> (cx=<optimized out>) at js/src/vm/StringType-inl.h:289
#8  js::AllocateInlineString<(js::AllowGC)1, unsigned char> (cx=<optimized out>, len=18, chars=0x7ffffffdd9a8) at js/src/vm/StringType-inl.h:41
#9  0x0000000000cecc59 in js::NewInlineString<(js::AllowGC)1, unsigned char> (cx=0x7ffff5f17000, chars=...) at js/src/vm/StringType-inl.h:60
#10 js::NewStringCopyNDontDeflate<(js::AllowGC)1, unsigned char> (cx=0x7ffff5f17000, s=<optimized out>, n=18) at js/src/vm/StringType.cpp:1558
#11 0x0000000000ced02b in js::NewStringCopyUTF8N<(js::AllowGC)1> (cx=cx@entry=0x7ffff5f17000, utf8=...) at js/src/vm/StringType.cpp:1629
#12 0x0000000000a60cdb in js::NewStringCopyUTF8Z<(js::AllowGC)1> (utf8=..., cx=0x7ffff5f17000) at js/src/vm/StringType.h:1497
#13 JS_NewStringCopyUTF8Z (cx=0x7ffff5f17000, s=...) at js/src/jsapi.cpp:5819
#14 0x0000000000a70a93 in js::ErrorToException (cx=<optimized out>, reportp=0x7ffffffddc80, callback=<optimized out>, userRef=<optimized out>) at js/src/jsexn.cpp:674
#15 0x0000000000bc9b7e in js::ReportErrorNumberVA (cx=cx@entry=0x7ffff5f17000, flags=<optimized out>, flags@entry=0, callback=callback@entry=0xbbdbc0 <js::GetErrorMessage(void*, unsigned int)>, userRef=userRef@entry=0x0, errorNumber=errorNumber@entry=116, argumentsType=argumentsType@entry=js::ArgumentsAreASCII, ap=0x7ffffffddd60) at js/src/vm/JSContext.cpp:836
#16 0x0000000000a5a3e8 in JS_ReportErrorNumberASCIIVA (cx=0x7ffff5f17000, errorCallback=0xbbdbc0 <js::GetErrorMessage(void*, unsigned int)>, userRef=0x0, errorNumber=116, ap=ap@entry=0x7ffffffddd60) at js/src/jsapi.cpp:6474
#17 0x0000000000a5a498 in JS_ReportErrorNumberASCII (cx=cx@entry=0x7ffff5f17000, errorCallback=errorCallback@entry=0xbbdbc0 <js::GetErrorMessage(void*, unsigned int)>, userRef=userRef@entry=0x0, errorNumber=errorNumber@entry=116) at js/src/jsapi.cpp:6463
#18 0x0000000000bc6556 in js::ReportOverRecursed (maybecx=0x7ffff5f17000, errorNumber=116) at js/src/vm/JSContext.cpp:335
#19 0x000000000095b8d8 in js::jit::CheckSimulatorRecursionLimitWithExtra (extra=0, cx=0x7ffff5f17000) at js/src/jit/VMFunctions.cpp:152
#20 js::jit::CheckOverRecursedWithExtra (cx=0x7ffff5f17000, frame=0x7ffff49fb6a8, extra=0, earlyCheck=<optimized out>) at js/src/jit/VMFunctions.cpp:215
#21 0x0000000000a01199 in vixl::Simulator::VisitCallRedirection (this=0x7ffff5f3b000, instr=0x7ffff5f8b0e8) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:636
#22 0x0000000000a0abd5 in vixl::Simulator::VisitException (this=0x7ffff5f3b000, instr=<optimized out>) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:479
#23 0x00000000009acbb8 in vixl::Decoder::VisitException (this=<optimized out>, instr=0x7ffff5f8b0e8) at js/src/jit/arm64/vixl/Decoder-vixl.cpp:872
#24 0x00000000009ec6d5 in vixl::Decoder::Decode (instr=<optimized out>, this=<optimized out>) at js/src/jit/arm64/vixl/Decoder-vixl.h:158
#25 vixl::Simulator::ExecuteInstruction (this=this@entry=0x7ffff5f3b000) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:195
#26 0x0000000000a3715c in vixl::Simulator::Run (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:70
#27 0x0000000000a0079c in vixl::Simulator::call (this=0x7ffff5f3b000, entry=entry@entry=0x32d26dc39960 "\376w\277\251\375\003", argument_count=argument_count@entry=8) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:327
#28 0x00000000007bfe14 in EnterJit (cx=<optimized out>, cx@entry=0x7ffff5f17000, state=..., code=0x32d26dc59350 "\237#") at js/src/jit/Jit.cpp:101
#29 0x00000000007c074c in js::jit::MaybeEnterJit (cx=cx@entry=0x7ffff5f17000, state=...) at js/src/jit/Jit.cpp:163
#30 0x00000000005a9cd1 in js::RunScript (cx=0x7ffff5f17000, state=...) at js/src/vm/Interpreter.cpp:402
#31 0x00000000005aa4f7 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f17000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:489
#32 0x00000000005aa80d in InternalCall (cx=0x7ffff5f17000, args=...) at js/src/vm/Interpreter.cpp:516
[...]
#113 0x00000000005aa80d in InternalCall (cx=0x7ffff5f17000, args=...) at js/src/vm/Interpreter.cpp:516
#114 0x00000000005aa95a in js::CallFromStack (cx=<optimized out>, args=...) at js/src/vm/Interpreter.cpp:522
#115 0x00000000006925e3 in js::jit::DoCallFallback (cx=<optimized out>, frame=0x7ffff4abf5a8, stub_=<optimized out>, argc=<optimized out>, vp=0x7ffff4abf540, res=...) at js/src/jit/BaselineIC.cpp:2372
#116 0x0000000000a00dc3 in vixl::Simulator::VisitCallRedirection (this=0x7ffff5f3b000, instr=0x7ffff5f88288) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:646
#117 0x0000000000a0abd5 in vixl::Simulator::VisitException (this=0x7ffff5f3b000, instr=<optimized out>) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:479
#118 0x00000000009acbb8 in vixl::Decoder::VisitException (this=<optimized out>, instr=0x7ffff5f88288) at js/src/jit/arm64/vixl/Decoder-vixl.cpp:872
#119 0x00000000009ec6d5 in vixl::Decoder::Decode (instr=<optimized out>, this=<optimized out>) at js/src/jit/arm64/vixl/Decoder-vixl.h:158
#120 vixl::Simulator::ExecuteInstruction (this=this@entry=0x7ffff5f3b000) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:195
#121 0x0000000000a3715c in vixl::Simulator::Run (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:70
#122 0x0000000000a0079c in vixl::Simulator::call (this=0x7ffff5f3b000, entry=entry@entry=0x32d26dc39960 "\376w\277\251\375\003", argument_count=argument_count@entry=8) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:327
#123 0x00000000007bfe14 in EnterJit (cx=<optimized out>, cx@entry=0x7ffff5f17000, state=..., code=0x32d26dc59350 "\237#") at js/src/jit/Jit.cpp:101
#124 0x00000000007c074c in js::jit::MaybeEnterJit (cx=cx@entry=0x7ffff5f17000, state=...) at js/src/jit/Jit.cpp:163
#125 0x00000000005a9cd1 in js::RunScript (cx=0x7ffff5f17000, state=...) at js/src/vm/Interpreter.cpp:402
#126 0x00000000005aa4f7 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f17000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:489
#127 0x00000000005aa80d in InternalCall (cx=0x7ffff5f17000, args=...) at js/src/vm/Interpreter.cpp:516
rax	0x0	0
rbx	0x7ffff492f040	140737296658496
rcx	0x7ffff6c282ad	140737333330605
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7ffffffdd900	140737488214272
rsp	0x7ffffffdd900	140737488214272
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4780	140737354024832
r10	0x0	0
r11	0x0	0
r12	0x7ffff5f17000	140737319628800
r13	0x1b	27
r14	0x7ffff5f170c8	140737319629000
r15	0x20	32
rip	0x478404 <js::gc::IsInsideNursery(js::gc::Cell const*)+68>
=> 0x478404 <js::gc::IsInsideNursery(js::gc::Cell const*)+68>:	movl   $0x0,0x0
   0x47840f <js::gc::IsInsideNursery(js::gc::Cell const*)+79>:	ud2



This is ARM64 only and seems to happen while trying to handle an over-recursion error. Marking s-s until investigated since it is a GC assertion.

Chris Peterson [:cpeterson]

Updated

•

6 years ago

Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update,bisect] [geckoview:crow]

Sean Stangl [:sstangl]

Comment 1

•

6 years ago

Setting ni to remind myself to look at this later.

Flags: needinfo?(sstangl)

Daniel Veditz [:dveditz]

Updated

•

6 years ago

Keywords: sec-high

Liz Henry (:lizzard) (relman/hg->git project)

Comment 2

•

6 years ago

Tracking for 62.

status-firefox63: --- → ?

tracking-firefox62: --- → +

tracking-firefox63: --- → ?

Flags: needinfo?(sstangl)

Liz Henry (:lizzard) (relman/hg->git project)

Comment 3

•

6 years ago

Sean, can you investigate?

Flags: needinfo?(sstangl)

Pascal Chevrel:pascalc (PTO until April 26)

Updated

•

6 years ago

tracking-firefox63: ? → +

Liz Henry (:lizzard) (relman/hg->git project)

Comment 4

•

6 years ago

Steven, can you help find an owner to look into this sec-high issue? Thanks!

Flags: needinfo?(sdetar)

Steven DeTar [:sdetar]

Comment 5

•

6 years ago

Liz, this is on our list of ARM64 bugs to investigate and address.  Sean is working through the list, and eventually we will get to looking at this bug and provide an update.

Steven DeTar [:sdetar]

Updated

•

6 years ago

Flags: needinfo?(sdetar)

Ryan VanderMeulen [:RyanVM]

Comment 6

•

6 years ago

This isn't going to make 62 at this point.

status-firefox61: --- → wontfix

status-firefox62: affected → wontfix

status-firefox63: ? → affected

status-firefox-esr52: --- → unaffected

status-firefox-esr60: --- → affected

Ted Campbell [:tcampbell]

Assignee

Comment 7

•

6 years ago

Testcase overruns the stack, which for simulator builds with jemalloc has a good chance of landing in GC trailer. This is not a GC bug. This testcase writes 20000*8B of arguments each recursive call in the EnterJit trampoline. Windows builds would be unaffected. It is unclear if non-simulator / non-shell builds have problems in practice. We probably need a more rigorous definition of our stack limits and better sanity checks for parameterizations. Particularly if we squeeze stack sizes for Fission.

Assignee: nobody → tcampbell

Flags: needinfo?(sstangl)

Ted Campbell [:tcampbell]

Assignee

Comment 8

•

6 years ago

Simulator only -> sec-other.

In other configurations (and full Gecko) we have much more space between the JS stack limit and the system stack limit. Probably worth cleaning up these parameters in another bug.

Keywords: sec-high → sec-other

Ted Campbell [:tcampbell]

Assignee

Comment 9

•

6 years ago

Attached file Bug 1463375 - Increase arm64 simulator stack protection size — Details

The simulator uses a protection area instead of guard pages. Increase
the size of this protection to be larger than worst-case frame size for
EnterJit trampolie.

MozReview-Commit-ID: 87I5cGJHLmy

Jan de Mooij [:jandem]

Comment 10

•

6 years ago

Comment on attachment 9007228 [details]
Bug 1463375 - Increase arm64 simulator stack protection size

Jan de Mooij [:jandem] has approved the revision.

Attachment #9007228 - Flags: review+

Ted Campbell [:tcampbell]

Assignee

Comment 11

•

6 years ago

Simulator-only. No uplifts planned unless fuzzing team thinks they are useful.

status-firefox63: affected → wontfix

status-firefox-esr60: affected → wontfix

Priority: -- → P1

Jan de Mooij [:jandem]

Updated

•

6 years ago

Group: javascript-core-security

Keywords: sec-other

Ted Campbell [:tcampbell]

Assignee

Updated

•

6 years ago

Keywords: checkin-needed

Pulsebot

Comment 12

•

6 years ago

Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa33ce0e26a4
Increase arm64 simulator stack protection size. r=jandem

Keywords: checkin-needed

Cosmin Sabou [:CosminS]

Comment 13

•

6 years ago

bugherder

https://hg.mozilla.org/mozilla-central/rev/fa33ce0e26a4

Status: NEW → RESOLVED

Closed: 6 years ago

status-firefox64: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → mozilla64

Comment hidden (Intermittent Failures Robot)

Arthur Iakab [arthur_iakab]

Comment 15

•

5 years ago

Recent failure https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=22194fd99032f5b3bdfe4fcb1a8fc1472c908451&selectedJob=229029989&searchStr=linux%2Cdebug%2Cmochitests%2Cwith%2Ce10s%2Ctest-linux32%2Fdebug-mochitest-e10s-3%2Cm-e10s%283%29

Log failure https://treeherder.mozilla.org/logviewer.html#?job_id=229029989&repo=autoland

Status: RESOLVED → REOPENED

Resolution: FIXED → ---

Christian Holler (:decoder)

Reporter

Comment 16

•

5 years ago

Please open a new bug for that failure, it is unlikely the same issue as in this bug. The assertion here is a generic one that can trigger in all sorts of situations.

Status: REOPENED → RESOLVED

Closed: 6 years ago → 5 years ago

Flags: needinfo?(aiakab)

Resolution: --- → FIXED

Arthur Iakab [arthur_iakab]

Comment 17

•

5 years ago

@Christian Holler, thank you for the info. Bug 1463375 was created for that failure.

Flags: needinfo?(aiakab)

Comment hidden (Intermittent Failures Robot)