163323 - Mozilla and xpcshell crash on string.split(/\b\W+(\b|$)/g) [@ str_split]

Status: VERIFIED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Martin Honnen]

I am trying to write a regular expression to split a sentence into words.
One of my attempts is
  /\b\W+(\b|$)/g
which works fine with IE6, doesn't work as I want with Netscape 4 but doesn't
crash, and crashes with both Mozilla 1.0 inside a HTML page and with the
xpcshell (tested on WinXP).
Therefore I file the bug on the JavaScript engine.
I will attach a test case that can be loaded with the xpcshell to demonstrate
the crash, and a test case to load into the browser.

Comment 1

[Martin Honnen]

Attachment: test case (load in xpxshell and crashes with the second regular expression)

It is not a minimal test case as it contains code to run the script in both the
xpcshell and the browser and as I have included an example with a similar
regular expression which doesn't crash in the hope that that makes it easier to
find the bug.

Comment 2

[Martin Honnen]

Attachment: HTML test page (works with IE6 but crashes Mozilla 1.0)

This uses the .js file attachment 95747 [details]

Comment 3

[Adam Hauner]

WFM 2002081612/trunk/W2K
Crash 2002081706/1.0branch/W2K -> TB9513569Q
Crash NNPR1/W2K -> TB9512822Z

Comment 4

[Andrew Schultz]

worksforme (no crash) with Linux trunk 20020817, 1.0 release and 1.0 branch 20020814

Comment 5

[Wesha]

WFM 2002081808/winXP

Comment 6

[Phil Schwartau]

Attachment: Adam's Talkback incidents (2)

Comment 7

[Phil Schwartau]

Note the testcase centers on |string.split(re);|, i.e. calling 
String.prototype.split() with a regexp for a separator. This is
permitted by ECMA-262 Section 15.5.4.14. The regexps used are:

                        /\b\W+\b/g;
                        /\b\W+(\b|$)/g;

Don't know which one is causing the crash, because I have not yet
been able to reproduce the crash. Will keep trying.


Note the output for the second regexp differs in IE6 from Mozilla:

IE6
--------------------------------------------------
test sentence: Kibology for all. All for Kibology.
found 6 words: 
word 0: Kibology
word 1: for
word 2: all
word 3: All
word 4: for
word 5: Kibology.

--------------------------------------------------
test sentence: Kibology for all. All for Kibology.
found 6 words: 
word 0: Kibology
word 1: for
word 2: all
word 3: All
word 4: for
word 5: Kibology


Mozilla trunk 2002080508 
--------------------------------------------------
test sentence: Kibology for all. All for Kibology.
found 6 words:
word 0: Kibology
word 1: for
word 2: all
word 3: All
word 4: for
word 5: Kibology.

--------------------------------------------------
test sentence: Kibology for all. All for Kibology.
found 13 words:
word 0: Kibology
word 1:
word 2: for
word 3:
word 4: all
word 5:
word 6: All
word 7:
word 8: for
word 9:
word 10: Kibology
word 11:
word 12: 

Comment 8

[Phil Schwartau]

The crashes are at line 1840 of js/src/jsstr.c:

static JSBool
str_split(JSContext *cx, JSObject *obj, uintN argc, jsval *argv, jsval *rval)
{

          etc.
          etc.


#if JS_HAS_REGEXPS
 /*
  * Imitate perl's feature of including parenthesized substrings
  * that matched part of the delimiter in the new array, after the
  * split substring that was delimited.
  */
  if (re && sep->chars) {
    uintN num;
    JSSubString *parsub;

    for (num = 0; num < cx->regExpStatics.parenCount; num++) {
      if (limited && len >= limit)
        break;
      parsub = REGEXP_PAREN_SUBSTRING(&cx->regExpStatics, num);
      sub = js_NewStringCopyN(cx, parsub->chars, parsub->length, 0);

      if (!sub)  <<<----------------------------------------------- LINE 1840
        return JS_FALSE;
      v = STRING_TO_JSVAL(sub);
      if (!JS_SetElement(cx, arrayobj, len, &v))
        return JS_FALSE;
      len++;
    }
    sep->chars = NULL;
  }
#endif

Comment 9

[rogerl (gone)]

Looks like an optimizer bug - this crashes right away in the release build of
the  shell. Further, if I change

parsub = REGEXP_PAREN_SUBSTRING(&cx->regExpStatics, num);

to
parsub = getParsub(cx, num); 

(where getParsub is a function containing the one line above) then everything
works fine. Looking at the original assembly code, it seems as if the optimizer
has decided that the test
    
     ((jsuint)(num) < 9)

in the expansion of REGEXP_PAREN_SUBSTRING is always false.

Comment 10

[Phil Schwartau]

*** Bug 164235 has been marked as a duplicate of this bug. ***

Comment 11

[Phil Schwartau]

QA note: 

Using Mozilla trunk binary 20020828xx on WinNT. 
I can reproduce the crash by keying in the given URL:

javascript:
var words = "Kibology for all.".split(/\b\W+(\b|$)/g); alert(words); void 0;

However, I have never been able to reproduce the crash in the
standalone JS shell (debug or optimized), nor the xpcshell.

Of course, we replace |alert| with |print| in the shells -

Comment 12

[Phil Schwartau]

Note: we've had other bugs recently that were discovered on Windows
and reportedly have something to do with the Windows compiler:

bug 140852 
"String(819187200000) == '8191871:0000' in xpcshell, browser"

bug 160531
"xpcshell, browser corrupt display of certain integers"

bug 160602
"Browser crashes on (new Date()).getTime()"



Question: is the current bug related to bug 165313?
"Mozilla crashes on Adobe Acrobat Reader download page"

That crash can be reduced to two lines of JS:

                 var x = /a/;
                 var y = {p: /b/};


NOTE:

1. bug 165313 is impossible for me to duplicate in the JS shell,
   either debug or optimized, nor in the xpcshell. I can only
   reproduce it in Mozilla builds.

2. bug 165313 was first reported on Linux, and occurs both on 
   Linux and Windows -

Comment 13

[Phil Schwartau]

> Question: is the current bug related to bug 165313?
> "Mozilla crashes on Adobe Acrobat Reader download page"

> That crash can be reduced to two lines of JS:

>               var x = /a/;
>               var y = {p: /b/};


No, not related. Bug 165313 was effectively fixed on 2002-08-28.
Build dates of 2002-08-29 or higher do not crash on that anymore.

See http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/js/src/jsinterp.c
Version 3.110: "Disable new fp->objAtomMap code to relieve blocker bug 165201"

By "backing in" this code and backing it out again, rogerl was able to
trace the crash to this part of the code.


In the meantime, the current bug seems more to do with the Windows
compiler issues we've been having (see Comment above and Comment #9),
and not anything to do with regexps per se.

Therefore reassigning to Kenton and cc'ing David -

Comment 14

[Phil Schwartau]

Note though I could reproduce the crash with Mozilla trunk binary 20020828xx,
the crash was unreliable: I had to enter the given javascript:URL over and over:

javascript:
var words = "Kibology for all.".split(/\b\W+(\b|$)/g); alert(words); void 0;

Trying the same thing with Mozilla trunk 20020903xx, however,
I haven't been able to crash no matter how many times I try. 


QUESTIONS

1. Martin: are you still able to crash on this with an up-to-date build?

2. rogerl: is it possible that the same thing that fixed bug 165313,
   i.e. the backout in jsinterp.c, might have fixed this bug, too???


In the meantime, I will keep trying to reproduce this.
Is this a bug where Purify would help?

Comment 15

[Martin Honnen]

I do crash every time (I click the URL link above) with Netscape 7
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0
I don't crash with Mozilla 1.1
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
I don't have the resources to download nightlies

Comment 16

[rogerl (gone)]

No, I still consistently crash the release build with the latest pull (i.e. with
the jsinterp.c backout).  My 'fix' stills works (not that I'm recommending this
as a patch - I think we need to understand if this is a bogus compiler version)

Comment 17

[Adam Hauner]

WFM 2003032908/trunk/W2K

Comment 18

[Phil Schwartau]

Also WORKSFORME in my current trunk Mozilla WinNT binary 2003033105.
No matter how many times I load the testcase in Comment #2 or the
javascript:URL in the URL field above, I do not crash.

This does look like it was caused by the Windows compiler bugs
we were having (see Comment #9 and following). Those bugs have
now been fixed: 

See bug 140852, "String(819187200000) == '8191871:0000' in xpcshell, browser"
See bug 160602, "Large integers, e.g. getTime(), causing crash at 0x39393929"

Resolving the current bug as WORKSFORME -

Comment 19

[Phil Schwartau]

Based on Adam's and my results, marking Verified. Martin: thank you
for this report. Please reopen if a current trunk build still shows
this problem. 

For details on the Windows compiler issue, see bug 140852.