1406449 - Assertion failure: toStringEnd >= bufEnd, at js/src/jsscript.cpp:2707 with clone

Status: RESOLVED DUPLICATE of bug 1405766

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 19b32a138d08 (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 --ion-offthread-compile=off):

g = clone(class {}, {});


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0000000000a7a1f8 in JSScript::Create (cx=cx@entry=0x7ffff6948000, options=..., sourceObject=..., sourceObject@entry=..., bufStart=27855, bufEnd=27861, toStringStart=10, toStringEnd=18) at js/src/jsscript.cpp:2707
#0  0x0000000000a7a1f8 in JSScript::Create (cx=cx@entry=0x7ffff6948000, options=..., sourceObject=..., sourceObject@entry=..., bufStart=27855, bufEnd=27861, toStringStart=10, toStringEnd=18) at js/src/jsscript.cpp:2707
#1  0x0000000000a7a3cc in CreateEmptyScriptForClone (cx=0x7ffff6948000, src=src@entry=...) at js/src/jsscript.cpp:3727
#2  0x0000000000a7c2d3 in js::CloneScriptIntoFunction (cx=0x7ffff6948000, enclosingScope=..., enclosingScope@entry=..., fun=..., fun@entry=..., src=src@entry=...) at js/src/jsscript.cpp:3759
#3  0x00000000009fdccc in js::CloneFunctionAndScript (cx=0x7ffff6948000, fun=..., fun@entry=..., enclosingEnv=..., newScope=..., newScope@entry=..., allocKind=<optimized out>, proto=..., proto@entry=...) at js/src/jsfun.cpp:2293
#4  0x0000000000994e68 in CloneFunctionObject (cx=cx@entry=0x7ffff6948000, funobj=..., env=..., scope=scope@entry=...) at js/src/jsapi.cpp:3721
#5  0x0000000000995108 in JS::CloneFunctionObject (cx=0x7ffff6948000, funobj=..., funobj@entry=..., envChain=...) at js/src/jsapi.cpp:3747
#6  0x000000000046e688 in Clone (cx=0x7ffff6948000, argc=<optimized out>, vp=<optimized out>) at js/src/shell/js.cpp:3086
#7  0x000000000055d4f1 in js::CallJSNative (cx=0x7ffff6948000, native=0x46e340 <Clone(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:293
#8  0x0000000000551d1f in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff6948000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:495
[...]
#21 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:8664
rax	0x0	0
rbx	0x6ccf	27855
rcx	0x7ffff6c28a2d	140737333332525
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffffc2f0	140737488339696
rsp	0x7fffffffc280	140737488339584
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4740	140737354024768
r10	0x58	88
r11	0x7ffff6b9f750	140737332770640
r12	0xa	10
r13	0x6cd5	27861
r14	0x7fffffffc640	140737488340544
r15	0x1f10da0	32574880
rip	0xa7a1f8 <JSScript::Create(JSContext*, JS::ReadOnlyCompileOptions const&, JS::Handle<JSObject*>, unsigned int, unsigned int, unsigned int, unsigned int)+664>
=> 0xa7a1f8 <JSScript::Create(JSContext*, JS::ReadOnlyCompileOptions const&, JS::Handle<JSObject*>, unsigned int, unsigned int, unsigned int, unsigned int)+664>:	movl   $0x0,0x0
   0xa7a203 <JSScript::Create(JSContext*, JS::ReadOnlyCompileOptions const&, JS::Handle<JSObject*>, unsigned int, unsigned int, unsigned int, unsigned int)+675>:	ud2

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160106142307" and the hash "e1cdd78c15bc3e7eaa1c74a81e6cfdd61a85a796".
The "bad" changeset has the timestamp "20160106142707" and the hash "8c69c6036831f6126e64734af669f5c27d47b07f".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e1cdd78c15bc3e7eaa1c74a81e6cfdd61a85a796&tochange=8c69c6036831f6126e64734af669f5c27d47b07f

Comment 2

[Naveed Ihsanullah [:naveed]]

Jeff please take a look and reassign/prioritize as appropriate. Is an efaust changeset from last year really implicated here?

Comment 3

[Jeff Walden [:Waldo]]

Implementing classes would certainly be the first place where cloning a class might go wrong, yeah.

I'm trying to figure out what exactly clone() is supposed to do, what it's expected to handle and not handle, etc.  The story is curiously underdefined.  The entrypoints to cloning in the browser seem to be 1) interpreting a lambda, a class, or an arrow function; or 2) XBL.  But clone() goes beyond those in letting you set up a particular environment as well, which none of these seem to allow -- certainly not for a class.  So it seems likely that what's being tested here isn't reachable except through this shell-only function -- and if so, the question is why we should bother trying (and demonstrably failing) to support this at all.  Perhaps it's just fallout from having a bad JS::CloneFunctionObject API in the first place.  :-(

I see we made clone() fuzzable and all quite deliberately, so maybe someone affiliated with that decision can answer any of this.  jandem?

Comment 4

[Jan de Mooij [:jandem]]

Fixing in bug 1405766.

Comment 5

[Jan de Mooij [:jandem]]

(IMO the right fix is to make CloneFunctionObject robust against these oddball functions - we already have a number of checks there - rather than having it crash in mysterious ways.)