660747 - TM: perlstress-001.js failing without tracejit or methodjit

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Ubuntu 32 bit build.

 FAILED! [reported from test()] Section 180 of test - 
 FAILED! [reported from test()] regexp = /(abc|)ef/i
 FAILED! [reported from test()] string = 'ABCDEF'
 FAILED! [reported from test()] ERROR !!! regexp FAILED to match anything !!!
 FAILED! [reported from test()] Expect: EF,
 FAILED! [reported from test()] Actual: null
 FAILED! [reported from test()]  : Type mismatch, expected type string, actual type object Expected value '["HIJ"]', Actual value 'null' 

Guessing it's because it's falling back on YARR-interp.

Comment 1

[David Mandelin [:dmandelin]]

This WFM now. Would you mind retesting?

Comment 2

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

Linux 64 dbg nmnt (no methodjit no tracejit):

 FAILED! [reported from test()] Section 83 of test - 
 FAILED! [reported from test()] regexp = /(abc|)ef/
 FAILED! [reported from test()] string = 'abcdef'
 FAILED! [reported from test()] ERROR !!! regexp FAILED to match anything !!!
 FAILED! [reported from test()] Expect: ef,
 FAILED! [reported from test()] Actual: null
 FAILED! [reported from test()]  : Type mismatch, expected type string, actual type object Expected value '["hij"]', Actual value 'null'

Linux 32 nmnt:

 FAILED! [reported from test()] Section 83 of test - 
 FAILED! [reported from test()] regexp = /(abc|)ef/
 FAILED! [reported from test()] string = 'abcdef'
 FAILED! [reported from test()] ERROR !!! regexp FAILED to match anything !!!
 FAILED! [reported from test()] Expect: ef,
 FAILED! [reported from test()] Actual: null
 FAILED! [reported from test()]  : Type mismatch, expected type string, actual type object Expected value '["hij"]', Actual value 'null'

Comment 3

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

Configure command used for 64b: ../js/src/configure --disable-tracejit --disable-methodjit --enable-optimize --disable-debug

Comment 4

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

But, when I run the *correct* debug settings in comment 3, I also get the same result. :-)

Comment 5

[Andrew Paprocki]

I also separately hit this bug when I manually grafted the yarr upgrade patches on top of 1.8.5 standalone. (We build with yarr JIT disabled.)

Comment 6

[Andrew Paprocki]

I've found the issue. The upstream WebKit r87109, which was a reversion of a previous rev, was not reverted in SM. When I apply the diff for r87109 to the engine with JIT disabled this test then passes.

WebKit changeset r87109: http://trac.webkit.org/changeset/87109
WebKit bug 61306: http://bugs.webkit.org/show_bug.cgi?id=61306

Comment 7

[Andrew Paprocki]

Attachment: Revert YARR begin characters optimization

Comment 8

[Andrew Paprocki]

$ ./jstests.py ../shell/js ecma_3/RegExp
[  63|   0|   5] 100% ===============================================>|   14.0s
PASS
$

Comment 9

[David Mandelin [:dmandelin]]

Comment on attachment 576085 [details] [diff] [review]
Revert YARR begin characters optimization

Review of attachment 576085 [details] [diff] [review]:
-----------------------------------------------------------------

Sweet! Thanks for tracking this down. If you check it in, could you please include the WebKit rev number in the checkin comment?

Comment 10

[Andrew Paprocki]

I'm just whiteboarding it for checkin, I don't have access to do it myself.

Comment 11

[Andrew Paprocki]

Comment on attachment 576085 [details] [diff] [review]
Revert YARR begin characters optimization

I also flagged approval-mozilla-aurora to see if it is possible to land this there. This has no impact on users with JIT enabled (virtually all browser users), but it impacts me and other embedders on non-JIT platforms. WebKit has had this reversion in their tree for ~5 months now, so it seems very low risk.

Comment 12

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/ec749c25ed64

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/ec749c25ed64

Comment 14

[LegNeato]

I landed on mozilla-aurora:

http://hg.mozilla.org/releases/mozilla-aurora/rev/a8affcb9442c

Note it didn't apply cleanly but the hunk that failed was merely removing a line that is no longer in the file anyway (I think!).

Comment 15

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Christian Legnitto [:LegNeato] from comment #14)
> I landed on mozilla-aurora:
> 
> http://hg.mozilla.org/releases/mozilla-aurora/rev/a8affcb9442c

backed out because it was burning all builds

Comment 16

[Andrew Paprocki]

Attachment: Previous patch rebased to Aurora

The original mozilla-inbound patch burned Aurora because:

changeset:   80723:f2fb79b0d7d2
user:        Chris Leary <[e-mail]>
date:        Tue Nov 29 15:24:44 2011 -0800
summary:     Bug 691299: Lower maximum quantifier. (r=dmandelin, a=akeybl)

was applied to Aurora before this changeset and in mozilla-inbound this changeset was exists after this patch. I applied the patch manually and made sure mozilla-aurora builds with it applied.