1100910 - Assertion failure: 0, at js/src/frontend/BytecodeEmitter.cpp:7172

Status: RESOLVED DUPLICATE of bug 1105608

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 134d1cfc5c9c (build with --enable-debug --enable-optimize --enable-posix-nspr-emulation --enable-valgrind, run with --fuzzing-safe):

eval("export { x, y as z } from 'a'; @");


Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000059d78d in js::frontend::EmitTree (cx=0x391d5a0, 
    bce=0x7fff0abd4e40, pn=0x3929860)
    at js/src/frontend/BytecodeEmitter.cpp:7172
7172	        MOZ_ASSERT(0);
To enable execution of this file add
	add-auto-load-safe-path js/src/shell/js-gdb.gdb
line to your configuration file "/home/decoder/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/decoder/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
#0  0x000000000059d78d in js::frontend::EmitTree (cx=0x391d5a0, bce=0x7fff0abd4e40, pn=0x3929860) at js/src/frontend/BytecodeEmitter.cpp:7172
#1  0x000000000059fe69 in js::frontend::CompileScript (cx=cx@entry=0x391d5a0, alloc=<optimized out>, scopeChain=..., scopeChain@entry=..., evalCaller=evalCaller@entry=..., options=..., srcBuf=..., source_=0x7f5e8380cef8, staticLevel=staticLevel@entry=3, extraSct=extraSct@entry=0x0) at js/src/frontend/BytecodeCompiler.cpp:397
#2  0x000000000051a572 in EvalKernel (cx=cx@entry=0x391d5a0, args=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., scopeobj=scopeobj@entry=..., pc=<optimized out>) at js/src/builtin/Eval.cpp:336
#3  0x000000000051aa84 in js::DirectEval (cx=cx@entry=0x391d5a0, args=...) at js/src/builtin/Eval.cpp:462
#4  0x000000000067d9de in js::jit::DoCallFallback (cx=0x391d5a0, frame=0x7fff0abd6e70, stub_=<optimized out>, argc=1, vp=0x7fff0abd6e20, res=...) at js/src/jit/BaselineIC.cpp:8983
#5  0x00007f5e8666e31d in ?? ()
rax	0x0	0
rbx	0x0	0
rcx	0x853203cd	140043938300877
rdx	0x0	0
rsi	0x855f59d0	140043941272016
rdi	0x855f41c0	140043941265856
rbp	0xabd4840	140733373564992
rsp	0xabd4730	140733373564720
r8	0x8665d780	140043958474624
r9	0x632d616c	8247338199356891500
r10	0x855f1be0	140043941256160
r11	0x0	0
r12	0x3929860	59938912
r13	0xabd5b90	140733373569936
r14	0xabd4e40	140733373566528
r15	0x391d5a0	59889056
rip	0x59d78d <js::frontend::EmitTree(js::ExclusiveContext*, js::frontend::BytecodeEmitter*, js::frontend::ParseNode*)+5901>
=> 0x59d78d <js::frontend::EmitTree(js::ExclusiveContext*, js::frontend::BytecodeEmitter*, js::frontend::ParseNode*)+5901>:	movl   $0x7b,0x0
   0x59d798 <js::frontend::EmitTree(js::ExclusiveContext*, js::frontend::BytecodeEmitter*, js::frontend::ParseNode*)+5912>:	callq  0x404af0 <abort@plt>

Comment 1

[Christian Holler (:decoder)]

This is still appearing and nobody has been looking at it for over a month now. Ni from Jandem to find an owner.

Comment 2

[Jan de Mooij [:jandem]]

(In reply to Christian Holler (:decoder) from comment #1)
> This is still appearing and nobody has been looking at it for over a month
> now. Ni from Jandem to find an owner.

We're in EmitTree and pn->getKind() is PNK_EXPORT_FROM. Jason do you know who added this?

Comment 3

[Jason Orendorff [:jorendorff]]

Created attachment 8535636 [details] [diff] [review]
Assertion with `export ... from` syntax

Comment 4

[Jason Orendorff [:jorendorff]]

(In reply to Jan de Mooij [:jandem] from comment #2)
> We're in EmitTree and pn->getKind() is PNK_EXPORT_FROM. Jason do you know
> who added this?

Yep, Eddy and I did that. The plan was to support the syntax in the parser first, then the emitter and everywhere else. Forgot a node type. (The other node types, PNK_IMPORT_SPEC_LIST and such, only appear as children of the three statement-level nodes listed here.)