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

RESOLVED FIXED in Firefox 11

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: cdleary, Assigned: Andrew Paprocki)

Tracking

unspecified
mozilla11
x86
Linux
Points:
---

Firefox Tracking Flags

(firefox10 affected, firefox11 fixed)

Details

(Whiteboard: [qa-])

Attachments

(2 attachments)

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.
Assignee: general → dmandelin
This WFM now. Would you mind retesting?
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'
Configure command used for 64b: ../js/src/configure --disable-tracejit --disable-methodjit --enable-optimize --disable-debug
But, when I run the *correct* debug settings in comment 3, I also get the same result. :-)
(Assignee)

Comment 5

6 years ago
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.)
(Assignee)

Comment 6

6 years ago
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
(Assignee)

Comment 7

6 years ago
Created attachment 576085 [details] [diff] [review]
Revert YARR begin characters optimization
Attachment #576085 - Flags: review?(dmandelin)
(Assignee)

Comment 8

6 years ago
$ ./jstests.py ../shell/js ecma_3/RegExp
[  63|   0|   5] 100% ===============================================>|   14.0s
PASS
$
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?
Attachment #576085 - Flags: review?(dmandelin) → review+
(Assignee)

Comment 10

6 years ago
I'm just whiteboarding it for checkin, I don't have access to do it myself.
Keywords: checkin-needed
(Assignee)

Comment 11

6 years ago
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.
Attachment #576085 - Flags: approval-mozilla-aurora?
http://hg.mozilla.org/integration/mozilla-inbound/rev/ec749c25ed64
Assignee: dmandelin → andrew
Keywords: checkin-needed
Target Milestone: --- → mozilla11
https://hg.mozilla.org/mozilla-central/rev/ec749c25ed64
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Attachment #576085 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 14

6 years ago
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!).
(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
status-firefox10: --- → affected
status-firefox11: --- → fixed
(Assignee)

Comment 16

6 years ago
Created attachment 582544 [details] [diff] [review]
Previous patch rebased to Aurora

The original mozilla-inbound patch burned Aurora because:

changeset:   80723:f2fb79b0d7d2
user:        Chris Leary <cdleary@mozilla.com>
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.
Attachment #582544 - Flags: review+
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.