606882 - Crash [@ RegExp::executeInternal()]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

URL in bug crashes, see bug 604371 comment #8. I get a different stack.

     mozjs.dll!js::RegExp::executeInternal(JSContext * cx=0x1cbc4240,
js::RegExpStatics * res=0x1bad7a90, JSString * input=0x34544ab0, unsigned int *
lastIndex=0x002cd1cc, bool test=false, js::Value * rval=0x03ea0980)  Line 331 +
0xb bytes    C++
>	mozjs.dll!DoMatch(JSContext * cx=0x1cbc4240, js::RegExpStatics * res=0x1bad7a90, js::Value * vp=0x00000000, JSString * str=0x34544ab0, const RegExpPair & rep={...}, bool (JSContext *, js::RegExpStatics *, unsigned int, void *)* callback=0x6dca2fc0, void * data=0x002cd218, MatchControlFlags flags=TEST_GLOBAL_BIT)  Line 1855 + 0x2d bytes	C++
     mozjs.dll!str_match(JSContext * cx=, unsigned int argc=, js::Value * vp=) 
Line 1929 + 0x1c bytes    C++
     mozjs.dll!JSCompartment::wrap(JSContext * cx=, js::Value * vp=)  Line 133
+ 0x12 bytes    C++
     mozjs.dll!JS_EvaluateUCScriptForPrincipalsVersion(JSContext *
cx=0x1cbc4240, JSObject * obj=0x142430e0, JSPrincipals * principals=0x1acc7384,
const wchar_t * chars=0x002cd5e8, unsigned int length=0x0000001b, const char *
filename=0x1bb79d38, unsigned int lineno=0x000004e2, unsigned __int64 *
rval=0x00000000, JSVersion version=JSVERSION_DEFAULT)  Line 4857 + 0x22 bytes  
 C++
     xul.dll!nsJSContext::EvaluateString(const nsAString_internal &
aScript={...}, void * aScopeObject=0x00000000, nsIPrincipal *
aPrincipal=0x00000001, const char * aURL=0x1bb79d38, unsigned int
aLineNo=0x000004e2, unsigned int aVersion=0x00000000, nsAString_internal *
aRetValue=0x00000000, int * aIsUndefined=0x002cd514)  Line 1724 + 0x5d bytes   
C++
     xul.dll!nsScriptLoader::EvaluateScript(nsScriptLoadRequest *
aRequest=0x23e0b2e0, const nsString & aScript={...})  Line 813 + 0x3d bytes   
C++
     xul.dll!nsScriptLoader::ProcessRequest(nsScriptLoadRequest *
aRequest=0x00000000)  Line 716 + 0xc bytes    C++
     xul.dll!nsScriptLoader::ProcessScriptElement(nsIScriptElement *
aElement=0x00000000)  Line 668 + 0x8 bytes    C++
     xul.dll!AtomImpl::IsStaticAtom()  + 0x300918 bytes    C++

Comment 1

[Bob Clary [:bc] (inactive)]

Note the crash in bug 604371 comment #8 was on trunk from this morning. Also note the url is associated with the socorro signature js::RegExp::execute(JSContext*, JSString*, unsigned int*, bool, js::Value*)

Comment 2

[Bob Clary [:bc] (inactive)]

On 64 bit linux

http://www.charismamag.com/index.php/features/2010/may/28114-vision-2020
http://www.charismamag.com/index.php/features/2010/april-?start=4

I'm seeing stacks like:

Operating system: Linux
                  0.0.0 Linux 2.6.18-194.17.1.el5 #1 SMP Wed Sep 29 12:50:31 EDT 2010 x86_64
CPU: amd64
     family 6 model 44 stepping 2
     2 CPUs

Crash reason:  SIGSEGV
Crash address: 0x2b4300000000

Thread 0 (crashed)
 0  0x2b4300000000
    rbx = 0x00000001   r12 = 0xaaaf6958   r13 = 0x00000000   r14 = 0xffffffff
    r15 = 0xaf2a5a50   rip = 0x00000000   rsp = 0xef9c1b20   rbp = 0x00000000
    Found by: given as instruction pointer in context
 1  libxul.so!JSC::Yarr::executeRegex [RegexJIT.h : 96 + 0x1f]
    rip = 0x6b3997fc   rsp = 0xef9c1b60
    Found by: stack scanning
 2  libxul.so!js::assertSameCompartment<JSObject*, js::Value> [jscntxtinlines.h : 634 + 0x12]
    rip = 0x6b458f26   rsp = 0xef9c1b70
    Found by: stack scanning
 3  libxul.so!js::RegExp::executeInternal [jsregexpinlines.h : 311 + 0x4f]
    rip = 0x6b39a0c0   rsp = 0xef9c1bd0
    Found by: stack scanning
 4  libxul.so!js_NativeGetInline [jsobj.cpp : 4878 + 0x13]
    rip = 0x6b450ef3   rsp = 0xef9c1c80
    Found by: stack scanning
 5  libxul.so!js::RegExp::execute [jsregexpinlines.h : 129 + 0x31]
    rip = 0x6b3998e6   rsp = 0xef9c1ca0
    Found by: stack scanning
 6  libxul.so!DoMatch [jsstr.cpp : 1852 + 0x31]
    rip = 0x6b4ccb53   rsp = 0xef9c1d00
    Found by: stack scanning
 7  libxul.so!js::Value::isObject [jsvalue.h : 487 + 0xb]
    rip = 0x6a3932ee   rsp = 0xef9c1d10
    Found by: stack scanning
 8  libxul.so!BuildFlatMatchArray [jsstr.cpp : 1879 + 0xa]
    rip = 0x6b4ccd92   rsp = 0xef9c1d18
    Found by: stack scanning
 9  libxul.so!JSContext::regExpStatics [jscntxtinlines.h : 115 + 0x13]
    rip = 0x6b492f9a   rsp = 0xef9c1d80
    Found by: stack scanning
10  libxul.so!str_match [jsstr.cpp : 1926 + 0x3e]
    rip = 0x6b4cd0b7   rsp = 0xef9c1da0
    Found by: stack scanning

Comment 3

[Bob Clary [:bc] (inactive)]

Attachment: semi reduced testcase

crashes 64bit linux at least. not mac 32bit though.

Comment 4

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: More reduced test case.

Making the regexp case-sensitive prevents the crash.

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: Shell crasher.

Comment 6

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: Shell crasher.

More minimal -- we should go back to the original pattern when this one is diagnosed to look for more crashers that I might have lost in the reduction.

Notably, if you change the \d+ to a \d? we run into an infinite loop instead of a crash.

Comment 7

[Bob Clary [:bc] (inactive)]

cdleary: I get a different stack for another regexp related crash on that site. Is this the same issue?

http://www.charismamag.com/index.php/charisma-channels/spiritual-growth/18968-the-lord-shall-fight-for-you-

Comment 8

[Nicholas Nethercote [inactive]]

(In reply to comment #6)
> 
> More minimal -- we should go back to the original pattern when this one is
> diagnosed to look for more crashers that I might have lost in the reduction.

I get a crash on X64, but not on i386.
 
> Notably, if you change the \d+ to a \d? we run into an infinite loop instead of
> a crash.

I get (AFAICT) the infinite loop with this change on both X64 and i386.

On X64 Valgrind says this:

==8437== Memcheck, a memory error detector
==8437== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==8437== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==8437== Command: debug64/js a.js
==8437== 
==8437== Warning: client switching stacks?  SP change: 0x7feffe4c8 --> 0x0
==8437==          to suppress, use: --max-stackframe=34342954184 or greater
==8437== 
==8437== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==8437==  Access not within mapped region at address 0x8
==8437==    at 0x435F05: JSC::Yarr::RegexCodeBlock::execute(unsigned short const*, unsigned int, unsigned int, int*) (RegexJIT.h:78)

The stack pointer is changing to zero?  Weird.  Not sure if that's helpful.

Comment 9

[Julian Seward [:jseward]]

(In reply to comment #8)
> The stack pointer is changing to zero?  Weird.  Not sure if that's helpful.

Stack is trashed, and rsp gets zeroed when callee saved registers are
restored in some prologue, perhaps?

Comment 11

[Paul Biggar]

"ABC".match("A+(?:X?(?:|(?:))(?:(?:B)?C+w?w?)?)*");

is the test case from 619585. This segfaults on Mac 64bit.

Comment 12

[David Mandelin [:dmandelin]]

I believe this is fixed by http://trac.webkit.org/changeset/72781. I'm going to try to apply that patch to our tree.

Comment 13

[David Mandelin [:dmandelin]]

Attachment: Patch (import yarr changeset 72781)

Comment 17

[Daniel Veditz [:dveditz]]

Making this a security bug because security bugs got duped to this.

Comment 18

[David Mandelin [:dmandelin]]

http://hg.mozilla.org/tracemonkey/rev/cc00a28bac97

Comment 20

[Chris Leary [:cdleary] (not checking bugmail)]

cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/cc00a28bac97