Closed Bug 1402535 Opened 7 years ago Closed 7 years ago

Assertion failure: false (TestIntegrityLevel(cx, obj, IntegrityLevel::Frozen, &frozen)), at js/src/builtin/ModuleObject.cpp:895

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox57 --- wontfix
firefox58 --- fixed

People

(Reporter: decoder, Assigned: jonco)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, bugmon, testcase, Whiteboard: [fuzzblocker] [jsbugmon:update])

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 2cd3752963fc (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe): stackTest(function() { let m = parseModule(``); m.declarationInstantiation(); }); Backtrace: received signal SIGSEGV, Segmentation fault. 0x00000000004337aa in IsObjectFrozen (obj=..., cx=<optimized out>) at js/src/builtin/ModuleObject.cpp:895 #0 0x00000000004337aa in IsObjectFrozen (obj=..., cx=<optimized out>) at js/src/builtin/ModuleObject.cpp:895 #1 0x00000000005aca58 in IsObjectFrozen (obj=..., cx=<optimized out>) at js/src/builtin/ModuleObject.cpp:904 #2 IsObjectPropertyFrozen (cx=0x7ffff6955000, obj=..., slot=<optimized out>) at js/src/builtin/ModuleObject.cpp:903 #3 0x00000000005acb28 in js::ModuleObject::IsFrozen (cx=cx@entry=0x7ffff6955000, self=self@entry=...) at js/src/builtin/ModuleObject.cpp:910 #4 0x00000000005a74be in js::ModuleObject::instantiateFunctionDeclarations (cx=cx@entry=0x7ffff6955000, self=self@entry=...) at js/src/builtin/ModuleObject.cpp:1037 #5 0x0000000000c3f54f in intrinsic_InstantiateModuleFunctionDeclarations (cx=0x7ffff6955000, argc=<optimized out>, vp=<optimized out>) at js/src/vm/SelfHosting.cpp:2100 #6 0x000019c234df9943 in ?? () #7 0x00007ffff46902b0 in ?? () #8 0x00007fffffffc8b8 in ?? () #9 0x00007fffffffc910 in ?? () #10 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x7fffffffc610 140737488340496 rcx 0x7ffff6c28a2d 140737333332525 rdx 0x0 0 rsi 0x7ffff6ef7770 140737336276848 rdi 0x7ffff6ef6540 140737336272192 rbp 0x7fffffffc5e0 140737488340448 rsp 0x7fffffffc5e0 140737488340448 r8 0x7ffff6ef7770 140737336276848 r9 0x7ffff7fe4740 140737354024768 r10 0x58 88 r11 0x7ffff6b9f750 140737332770640 r12 0x7fffffffc608 140737488340488 r13 0x7fffffffc860 140737488341088 r14 0x7fffffffc668 140737488340584 r15 0x1 1 rip 0x4337aa <IsObjectFrozen(JS::HandleObject, JSContext*)+28> => 0x4337aa <IsObjectFrozen(JS::HandleObject, JSContext*)+28>: movl $0x0,0x0 0x4337b5 <IsObjectFrozen(JS::HandleObject, JSContext*)+39>: ud2 This is trigger-happy with the new stackTest function. Maybe something in parseModule isn't handling the recursion checks properly? It would be good if someone could help investigating this because this blocks all other testing with stackTest.
Jon, could you help me find the right person for this? Bisections are not going to work here since it depends on the new testing function I added. Thanks!
Flags: needinfo?(jcoppeard)
Whiteboard: [jsbugmon:update,bisect][fuzzblocker] → [fuzzblocker] [jsbugmon:update]
JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/a69946757ded user: Christian Holler date: Wed Sep 20 14:19:21 2017 +0200 summary: Bug 1395240 - Implement stackTest function for JS stack OOM testing. r=jandem This iteration took 272.121 seconds to run.
Assignee: nobody → jcoppeard
Flags: needinfo?(jcoppeard)
The check to test whether module objects are frozen is fallible due to the possibility of over-recursion. The patch adds error handling during the check.
Attachment #8911779 - Flags: review?(evilpies)
Comment on attachment 8911779 [details] [diff] [review] bug1402535-module-check-frozen Review of attachment 8911779 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/builtin/ModuleObject.cpp @@ +908,2 @@ > { > + static const mozilla::EnumSet<ModuleSlot> slotsToCheck = { TIL EnumSets exists.
Attachment #8911779 - Flags: review?(evilpies) → review+
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f2881b8508ab Handle errors while checking that a module object is frozen r=evilpie
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Can this ride the 58 train or should we consider backporting it to Beta as well?
Flags: needinfo?(jcoppeard)
Flags: in-testsuite+
(In reply to Ryan VanderMeulen [:RyanVM] from comment #7) This issue only affects debug-mode assertions, and the feature (modules) is preffed off by default anyway. I think this can ride the trains.
Flags: needinfo?(jcoppeard)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: