Bug 18687

Summary: REGRESSION(r32220): ecma/Array/ test now fails in GMT(BST)
Product: WebKit Reporter: Simon Hollingshead <simon.hollingshead>
Component: JavaScriptCoreAssignee: Alexey Proskuryakov <ap>
Severity: Major CC: ap
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Description Flags
proposed fix none

Description Simon Hollingshead 2008-04-22 15:45:35 PDT
Before http://trac.webkit.org/projects/webkit/changeset/32220 the test ecma/Array/ 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

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).