Closed Bug 816033 Opened 12 years ago Closed 12 years ago

Intermittent jsreftest.html?test=ecma_5/extensions/JSON-string-replacer-overflow.js | No test results reported. (SCRIPT)

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla24
Tracking Flags:
Tracking Status
firefox20 --- affected

People

(Reporter: emorley, Assigned: Waldo)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Use a jsapi-test for testing hash table internals, restrict initial JSON replacer set size to avoid trivial DOS, check for operation callbacks in the loop so slow-script works
4.96 KB, patch
luke
: review+
Details | Diff | Splinter Review 
Rev3 WINNT 5.1 mozilla-central opt test jsreftest on 2012-11-27 19:29:43 PST for push 3c3a8eed0578

slave: talos-r3-xp-095

https://tbpl.mozilla.org/php/getParsedLog.php?id=17395498&tree=Firefox

{
REFTEST TEST-START | file:///C:/talos-slave/test/build/jsreftest/tests/jsreftest.html?test=ecma_5/extensions/JSON-string-replacer-overflow.js | 1509 / 3202 (47%)
REFTEST TEST-UNEXPECTED-FAIL | file:///C:/talos-slave/test/build/jsreftest/tests/jsreftest.html?test=ecma_5/extensions/JSON-string-replacer-overflow.js | No test results reported. (SCRIPT)
}
Luke, please  can you take a look? :-)
Flags: needinfo?(luke)
Flags: needinfo?(luke) → needinfo?(jwalden+bmo)
status-firefox20: --- → affected
Failure rate too high; disabled on Windows opt builds whilst Jeff investigates:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c509026067ee
Whiteboard: [test disabled on Windows opt][leave open]
This started failing on WinXP debug builds as well. Investigating these sorts of failures almost never leads to anything useful, so I'm just disabling the test in debug as well.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a4129f091522
I'm guessing the 1<<23 loop sometimes just takes too long to run.  Given that parameter is determined by HashSet itself, we can't really change it.  But we can test it with a jsapi-test specifically of HashSet, which seems better in every way, so let's do that.

It's also probably a good idea to not naively do such ridiculously large allocations in the first place.  I capped the initial size so that bogus arrays passed in won't trigger crazy allocations.  Also I added an operation-callback-check to the loop, so if someone does try a really huge length, at least it can be slow-script-stopped.
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
Attachment #753491 - Flags: review?(luke)
Flags: needinfo?(jwalden+bmo)
Attachment #753491 - Flags: review?(luke) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/14eb4fb8c126
Whiteboard: [test disabled on Windows opt][leave open]
Target Milestone: --- → mozilla24
...and https://hg.mozilla.org/integration/mozilla-inbound/rev/d828c528e31e to remove one more test, that apparently escaped the patch here and made its way into another patch that I didn't push.  :-(
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: