867955 - Crash [@ __memcpy_ssse3_rep] with RegExp involved

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 70e0955ccc87 (run with --ion-eager):


function toPrinted(value) {
  value = value.replace(/\\n/g, 'NL')
}
var UBound = 0;
var actualvalues = [];
capture(this.toString());
capture([]);
function capture(val) {
  actualvalues[UBound] = val;
  UBound++;
  for (var i=0; i<UBound; i++)
    toPrinted(actualvalues[i]);
}

Comment 1

[Christian Holler (:decoder)]

Crash trace:

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3_rep () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3-rep.S:1297
1297    ../sysdeps/i386/i686/multiarch/memcpy-ssse3-rep.S: No such file or directory.
(gdb) bt
#0  __memcpy_ssse3_rep () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3-rep.S:1297
#1  0x0820cec6 in PodCopy<unsigned short> (nelem=<optimized out>, src=<optimized out>, dst=0xd47a7008) at /usr/include/bits/string3.h:52
#2  JSRope::flattenInternal<(JSRope::UsingBarrier)1> (this=, maybecx=0x90effc8) at js/src/vm/String.cpp:249
#3  0x0817b7fc in ensureLinear (cx=0x90effc8, this=) at js/src/vm/String.h:907
#4  DoMatch (cx=0x90effc8, res=0x90eeee8, str=, re=..., callback=0x8187fb0 <ReplaceRegExpCallback(JSContext*, js::RegExpStatics*, size_t, void*)>, data=0xffffc1c8, flags=REPLACE_ARGS, rval=
    $jsval(-nan(0xfff8200000000))) at js/src/jsstr.cpp:1714
#5  0x0818bd30 in str_replace_regexp (rdata=..., args=..., cx=0x90effc8) at js/src/jsstr.cpp:2526
#6  js::str_replace (cx=0x90effc8, argc=2, vp=0xffffc40c) at js/src/jsstr.cpp:2712
#7  0xf7fd2a33 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) x /i $pc
=> 0xf7df1146 <__memcpy_ssse3_rep+3446>:        movdqu 0x40(%eax),%xmm4
(gdb) info reg eax
eax            0xf75fffb8       -144703560


s-s due to potentially dangerous memcpy involved.

Comment 2

[Christian Holler (:decoder)]

Very similar looking testcase crashes on the heap instead:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff67cd282 in ?? ()
(gdb) bt
#0  0x00007ffff67cd282 in ?? ()
#1  0x00000000016e0d60 in ?? ()
#2  0x00007fffffffc230 in ?? ()
#3  0x0000000000622690 in execute (output=<optimized out>, length=4284826908, start=<optimized out>, input=0x7ffff6543238, this=0x16e0d70) at ../yarr/YarrJIT.h:135
#4  js::RegExpShared::execute (this=0x16e0d60, cx=0x16cf2e0, chars=0x7ffff6543238, length=8796082881820, lastIndex=0x7fffffffc2b0, matches=...) at /srv/repos/mozilla-central/js/src/vm/RegExpObject.cpp:554
#5  0x0000000000533725 in DoMatch (cx=0x16cf2e0, res=0x16ef000, str=<optimized out>, re=..., callback=0x540f50 <ReplaceRegExpCallback(JSContext*, js::RegExpStatics*, size_t, void*)>, data=0x7fffffffc470, flags=
    REPLACE_ARGS, rval=JSVAL_VOID) at /srv/repos/mozilla-central/js/src/jsstr.cpp:1728
#6  0x00000000005437b9 in str_replace_regexp (rdata=..., args=..., cx=0x16cf2e0) at /srv/repos/mozilla-central/js/src/jsstr.cpp:2526
#7  js::str_replace (cx=0x16cf2e0, argc=2, vp=0x7fffffffc868) at /srv/repos/mozilla-central/js/src/jsstr.cpp:2712
#8  0x00007ffff67cd482 in ?? ()
#9  0x0000000000000000 in ?? ()

Comment 3

[Robert Kaiser]

Do we have versions this affects? Only 23 or farther back?

Comment 4

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision b842d26dd5f0).
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   129593:ee14945b452c
parent:      128511:d989eab66df4
user:        Brian Hackett
date:        Thu Apr 11 18:39:32 2013 -0600
summary:     Bug 804676 - Remove dependence of Ion compilation on ScriptAnalysis::analyzeTypes.

This iteration took 17.008 seconds to run.

Comment 5

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   130603:ff9eed6225d7
parent:      130602:3519bc0b981a
parent:      130553:e474b6cfebce
user:        Ryan VanderMeulen
date:        Thu May 02 07:39:49 2013 -0400
summary:     Merge m-c to inbound.

Not all ancestors of this changeset have been checked.
Use bisect --extend to continue the bisection from
the common ancestor, 0274ab3783b1.

This iteration took 343.944 seconds to run.

Oops! We didn't test rev 3519bc0b981a, a parent of the blamed revision! Let's do that now.
We did not test rev 3519bc0b981a because it is not a descendant of either 70e0955ccc87 or b842d26dd5f0.
Rev 3519bc0b981a: Updating... Compiling... Testing... [Uninteresting] It didn't crash. (0.058 seconds)
good (not interesting) 
As expected, the parent's label is the opposite of the blamed rev's label.
Bisect lied to us! Parent rev 3519bc0b981a was also good!

Bisect blamed the merge because our initial range did not include one
of the parents.
The common ancestor of 3519bc0b981a and e474b6cfebce is 0274ab3783b1.
Rev 0274ab3783b1: Found cached shell...   Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.134 seconds)
bad (interesting) 
Consider re-running autoBisect with -s 0274ab3783b1 -e ff9eed6225d7
in a configuration where earliestWorking is before the common ancestor.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Christian Holler (:decoder) from comment #5)
> JSBugMon: Fix Bisection requested, result:

> Consider re-running autoBisect with -s 0274ab3783b1 -e ff9eed6225d7
> in a configuration where earliestWorking is before the common ancestor.

Cool. Christian will your robot follow up here or do we do this manually?

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to David Bolter [:davidb] from comment #6)
> (In reply to Christian Holler (:decoder) from comment #5)
> > JSBugMon: Fix Bisection requested, result:
> 
> > Consider re-running autoBisect with -s 0274ab3783b1 -e ff9eed6225d7
> > in a configuration where earliestWorking is before the common ancestor.
> 
> Cool. Christian will your robot follow up here or do we do this manually?

That just means bisect stepped over itself, it is unlikely (but may still be possible, just more difficult) to get a regression window.

Comment 8

[Daniel Veditz [:dveditz]]

several fixes for regressions from bug 804676 have gone in... call this WFM?

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I'm not sure how relevant this is to bug 867946 either.

Comment 10

[Christian Holler (:decoder)]

Marking WFM. Bug 867946 is likely unrelated, imo.