Closed Bug 1219877 Opened 4 years ago Closed 4 years ago

Assertion failure: !pc->sc->strict(), at js/src/frontend/Parser.cpp:6665

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox44 --- fixed
firefox45 --- fixed
b2g-v2.5 --- fixed

People

(Reporter: rforbes, Assigned: arai)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update,bisect])

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 7b6a80ca1f0d (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --no-threads):

"use strict"
let (i, get) {}

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004e4671 in js::frontend::Parser<js::frontend::FullParseHandler>::shouldParseLetDeclaration (this=this@entry=0x7fffffffcd90, parseDeclOut=parseDeclOut@entry=0x7fffffffc1a0) at js/src/frontend/Parser.cpp:6665
#0  0x00000000004e4671 in js::frontend::Parser<js::frontend::FullParseHandler>::shouldParseLetDeclaration (this=this@entry=0x7fffffffcd90, parseDeclOut=parseDeclOut@entry=0x7fffffffc1a0) at js/src/frontend/Parser.cpp:6665
#1  0x000000000050112a in js::frontend::Parser<js::frontend::FullParseHandler>::statement (this=this@entry=0x7fffffffcd90, yieldHandling=yieldHandling@entry=js::frontend::YieldIsName, canHaveDirectives=<optimized out>) at js/src/frontend/Parser.cpp:6798
#2  0x00000000005013a9 in js::frontend::Parser<js::frontend::FullParseHandler>::statements (this=this@entry=0x7fffffffcd90, yieldHandling=yieldHandling@entry=js::frontend::YieldIsName) at js/src/frontend/Parser.cpp:3204
#3  0x00000000004d7fa2 in js::frontend::Parser<js::frontend::FullParseHandler>::globalBody (this=this@entry=0x7fffffffcd90) at js/src/frontend/Parser.cpp:1010
#4  0x0000000000a08bc6 in BytecodeCompiler::compileScript (this=this@entry=0x7fffffffc720, scopeChain=..., scopeChain@entry=..., evalCaller=..., evalCaller@entry=...) at js/src/frontend/BytecodeCompiler.cpp:521
#5  0x0000000000a09383 in js::frontend::CompileScript (cx=cx@entry=0x7ffff6906c00, alloc=<optimized out>, scopeChain=scopeChain@entry=..., enclosingStaticScope=..., enclosingStaticScope@entry=..., evalCaller=evalCaller@entry=..., options=..., srcBuf=..., source_=source_@entry=0x0, extraSct=extraSct@entry=0x0, sourceObjectOut=sourceObjectOut@entry=0x0) at js/src/frontend/BytecodeCompiler.cpp:732
#6  0x000000000084525d in Compile (cx=cx@entry=0x7ffff6906c00, options=..., scopeOption=scopeOption@entry=HasSyntacticScope, srcBuf=..., script=..., script@entry=...) at js/src/jsapi.cpp:4124
#7  0x0000000000845431 in Compile (script=..., length=<optimized out>, chars=0x7ffff50f4400 u"\"use strict\"\r\nlet (i, get) {}\r\n", scopeOption=HasSyntacticScope, options=..., cx=0x7ffff6906c00) at js/src/jsapi.cpp:4133
#8  Compile (cx=cx@entry=0x7ffff6906c00, options=..., scopeOption=scopeOption@entry=HasSyntacticScope, bytes=<optimized out>, length=31, script=script@entry=...) at js/src/jsapi.cpp:4148
#9  0x0000000000856bb7 in Compile (cx=cx@entry=0x7ffff6906c00, options=..., scopeOption=scopeOption@entry=HasSyntacticScope, fp=fp@entry=0x7ffff50e5400, script=...) at js/src/jsapi.cpp:4159
#10 0x0000000000856bf2 in JS::Compile (cx=cx@entry=0x7ffff6906c00, options=..., file=file@entry=0x7ffff50e5400, script=..., script@entry=...) at js/src/jsapi.cpp:4199
#11 0x0000000000428947 in RunFile (compileOnly=false, file=0x7ffff50e5400, filename=0x7fffffffe34f "c22f9c953bdffd595948ea4267b9b1834d7e1729.js", cx=0x7ffff6906c00) at js/src/shell/js.cpp:500
#12 Process (cx=cx@entry=0x7ffff6906c00, filename=0x7fffffffe34f "c22f9c953bdffd595948ea4267b9b1834d7e1729.js", forceTTY=forceTTY@entry=false) at js/src/shell/js.cpp:628
#13 0x000000000048511a in ProcessArgs (op=0x7fffffffdd80, cx=0x7ffff6906c00) at js/src/shell/js.cpp:6006
#14 Shell (envp=<optimized out>, op=0x7fffffffdd80, cx=0x7ffff6906c00) at js/src/shell/js.cpp:6309
#15 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:6666
rax	0x0	0
rbx	0x7fffffffcd90	140737488342416
rcx	0x7ffff6ca4870	140737333839984
rdx	0x0	0
rsi	0x7ffff6f799d0	140737336809936
rdi	0x7ffff6f781c0	140737336803776
rbp	0x7fffffffc170	140737488339312
rsp	0x7fffffffc140	140737488339264
r8	0x7ffff7fd9780	140737353979776
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffffbf00	140737488338688
r11	0x7ffff6c26ee0	140737333325536
r12	0x7fffffffc1a0	140737488339360
r13	0x0	0
r14	0x1	1
r15	0x7fffffffcdc0	140737488342464
rip	0x4e4671 <js::frontend::Parser<js::frontend::FullParseHandler>::shouldParseLetDeclaration(bool*)+65>
=> 0x4e4671 <js::frontend::Parser<js::frontend::FullParseHandler>::shouldParseLetDeclaration(bool*)+65>:	movl   $0x1a09,0x0
   0x4e467c <js::frontend::Parser<js::frontend::FullParseHandler>::shouldParseLetDeclaration(bool*)+76>:	callq  0x4a5d10 <abort()>
|let| is consumed as TOK_NAME before parsing directive and setting strict mode.
could we just remove |MOZ_ASSERT(!pc->sc->strict());| there?
It's clear that peekShouldParseLetDeclaration should be called in sloppy mode, as "use strict" directive should already be parsed if exists, so moved the assertion there.
Assignee: nobody → arai.unmht
Attachment #8680843 - Flags: review?(shu)
Comment on attachment 8680843 [details] [diff] [review]
Allow let token with TOK_NAME in strict mode in Parser::shouldParseLetDeclaration.

Review of attachment 8680843 [details] [diff] [review]:
-----------------------------------------------------------------

Oh, great catch. Thanks for the patch!
Attachment #8680843 - Flags: review?(shu) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/6125cc2f07df1e7b95298b56e4f37cf64e44309b
Bug 1219877 - Allow let token with TOK_NAME in strict mode in Parser::shouldParseLetDeclaration. r=shu
Did this make the train? If not, could you request uplift for aurora? Thanks!
Flags: needinfo?(arai.unmht)
Comment on attachment 8680843 [details] [diff] [review]
Allow let token with TOK_NAME in strict mode in Parser::shouldParseLetDeclaration.

Thanks for reminder :)
hg.m.o says "milestone 45.0a1".

Approval Request Comment
[Feature/regressing bug #]: bug 932517
[User impact if declined]: no impact on opt build.  hits assertion failure in debug build and makes debugging/fuzzing hard.
[Describe test coverage new/current, TreeHerder]: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=6125cc2f07df
[Risks and why]: Very low, it changes only debug code
[String/UUID change made/needed]: None
Flags: needinfo?(arai.unmht)
Attachment #8680843 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/6125cc2f07df
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Comment on attachment 8680843 [details] [diff] [review]
Allow let token with TOK_NAME in strict mode in Parser::shouldParseLetDeclaration.

Given that this fix has been on Nightly for a few days, it seems safe to uplift to Aurora44.
Attachment #8680843 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion
You need to log in before you can comment on or make changes to this bug.