Bug 18687 - REGRESSION(r32220): ecma/Array/15.4.4.5-3.js test now fails in GMT(BST)
Summary: REGRESSION(r32220): ecma/Array/15.4.4.5-3.js test now fails in GMT(BST)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Major
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-22 15:45 PDT by Simon Hollingshead
Modified: 2008-05-21 10:19 PDT (History)
1 user (show)

See Also:


Attachments
proposed fix (1.74 KB, patch)
2008-04-23 01:44 PDT, Alexey Proskuryakov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hollingshead 2008-04-22 15:45:35 PDT
Before http://trac.webkit.org/projects/webkit/changeset/32220 the test ecma/Array/15.4.4.5-3.js passed, now returns:

Failure messages were:
testarr3[8] = Sat Jan 01 2000 00:00:00 GMT+0000 (GMT) FAILED! expected: Sat Jan 01 2000 00:00:00 GMT+0000 (GMT)
testarr3[9] = Sat Jan 01 2000 00:00:00 GMT+0000 (GMT) FAILED! expected: Sat Jan 01 2000 00:00:00 GMT+0000 (GMT)

This appears to be an issue with the array comparison, as the expected and actual results are identical.
Comment 1 Alexey Proskuryakov 2008-04-23 01:29:34 PDT
This is a mistake in the test. In GMT time zone, the array being sorted happens to contain two identical dates, but different Date objects don't compare as equal even if the dates are the same, and Array.sort() is not guaranteed to be stable by ECMA-262. It used to be stable before r32220, but now we use std::sort instead of mergesort.

We can either switch back to a stable sort, or fix the test.

This test also fails in Firefox, so I think that fixing it would be appropriate.
Comment 2 Alexey Proskuryakov 2008-04-23 01:38:38 PDT
Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=430427>.
Comment 3 Alexey Proskuryakov 2008-04-23 01:44:25 PDT
Created attachment 20767 [details]
proposed fix
Comment 4 Jon Honeycutt 2008-04-23 03:00:46 PDT
Comment on attachment 20767 [details]
proposed fix

r=me
Comment 5 Darin Adler 2008-04-23 09:14:49 PDT
Comment on attachment 20767 [details]
proposed fix

(Only half sarcastic.) But who's going to make the rest of the websites on the web resilient to sort instability?
Comment 6 Alexey Proskuryakov 2008-04-23 09:45:49 PDT
Comment on attachment 20767 [details]
proposed fix

Well, yeah, my assumption was that Firefox performed non-stable sort, too, because it was also failing this test. But looks like it is not, and the reason for the failure in their case is that the compare function is broken. So, we'll have to fix both the implementation and the test.
Comment 7 Alexey Proskuryakov 2008-04-23 09:49:54 PDT
Firefox bug about sort stability (fixed rather recently): <https://bugzilla.mozilla.org/show_bug.cgi?id=224128>.
Comment 8 Alexey Proskuryakov 2008-05-21 10:19:16 PDT
Fixed in <http://trac.webkit.org/changeset/33967> (switched to a stable sort, and also fixed the test).