js/src/tests/js1_5/Array/regress-157652.js@129ffea94266
js/src/tests/js1_5/Array/regress-157652.js
Sat, 03 Jan 2015 20:18:00 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Sat, 03 Jan 2015 20:18:00 +0100
- branch
- TOR_BUG_3246
- changeset 7
- 129ffea94266
- permissions
- -rw-r--r--
Conditionally enable double key logic according to:
private browsing mode or privacy.thirdparty.isolate preference and
implement in GetCookieStringCommon and FindCookie where it counts...
With some reservations of how to convince FindCookie users to test
condition and pass a nullptr when disabling double key logic.
1 // |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64/)||Android) -- No test results
2 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
3 /* This Source Code Form is subject to the terms of the Mozilla Public
4 * License, v. 2.0. If a copy of the MPL was not distributed with this
5 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
7 /*
8 *
9 * Date: 16 July 2002
10 * SUMMARY: Testing that Array.sort() doesn't crash on very large arrays
11 * See http://bugzilla.mozilla.org/show_bug.cgi?id=157652
12 *
13 * How large can a JavaScript array be?
14 * ECMA-262 Ed.3 Final, Section 15.4.2.2 : new Array(len)
15 *
16 * This states that |len| must be a a uint32_t (unsigned 32-bit integer).
17 * Note the UBound for uint32's is 2^32 -1 = 0xFFFFFFFF = 4,294,967,295.
18 *
19 * Check:
20 * js> var arr = new Array(0xFFFFFFFF)
21 * js> arr.length
22 * 4294967295
23 *
24 * js> var arr = new Array(0x100000000)
25 * RangeError: invalid array length
26 *
27 *
28 * We'll try the largest possible array first, then a couple others.
29 * We're just testing that we don't crash on Array.sort().
30 *
31 * Try to be good about memory by nulling each array variable after it is
32 * used. This will tell the garbage collector the memory is no longer needed.
33 *
34 * As of 2002-08-13, the JS shell runs out of memory no matter what we do,
35 * when trying to sort such large arrays.
36 *
37 * We only want to test that we don't CRASH on the sort. So it will be OK
38 * if we get the JS "out of memory" error. Note this terminates the test
39 * with exit code 3. Therefore we put
40 *
41 * |expectExitCode(3);|
42 *
43 * The only problem will arise if the JS shell ever DOES have enough memory
44 * to do the sort. Then this test will terminate with the normal exit code 0
45 * and fail.
46 *
47 * Right now, I can't see any other way to do this, because "out of memory"
48 * is not a catchable error: it cannot be trapped with try...catch.
49 *
50 *
51 * FURTHER HEADACHE: Rhino can't seem to handle the largest array: it hangs.
52 * So we skip this case in Rhino. Here is correspondence with Igor Bukanov.
53 * He explains that Rhino isn't actually hanging; it's doing the huge sort:
54 *
55 * Philip Schwartau wrote:
56 *
57 * > Hi,
58 * >
59 * > I'm getting a graceful OOM message on trying to sort certain large
60 * > arrays. But if the array is too big, Rhino simply hangs. Note that ECMA
61 * > allows array lengths to be anything less than Math.pow(2,32), so the
62 * > arrays I'm sorting are legal.
63 * >
64 * > Note below, I'm getting an instantaneous OOM error on arr.sort() for LEN
65 * > = Math.pow(2, 30). So shouldn't I also get one for every LEN between
66 * > that and Math.pow(2, 32)? For some reason, I start to hang with 100% CPU
67 * > as LEN hits, say, Math.pow(2, 31) and higher. SpiderMonkey gives OOM
68 * > messages for all of these. Should I file a bug on this?
69 *
70 * Igor Bukanov wrote:
71 *
72 * This is due to different sorting algorithm Rhino uses when sorting
73 * arrays with length > Integer.MAX_VALUE. If length can fit Java int,
74 * Rhino first copies internal spare array to a temporary buffer, and then
75 * sorts it, otherwise it sorts array directly. In case of very spare
76 * arrays, that Array(big_number) generates, it is rather inefficient and
77 * generates OutOfMemory if length fits int. It may be worth in your case
78 * to optimize sorting to take into account array spareness, but then it
79 * would be a good idea to file a bug about ineficient sorting of spare
80 * arrays both in case of Rhino and SpiderMonkey as SM always uses a
81 * temporary buffer.
82 *
83 */
84 //-----------------------------------------------------------------------------
85 var BUGNUMBER = 157652;
86 var summary = "Testing that Array.sort() doesn't crash on very large arrays";
87 var expect = 'No Crash';
88 var actual = 'No Crash';
90 printBugNumber(BUGNUMBER);
91 printStatus(summary);
93 expectExitCode(0);
94 expectExitCode(5);
96 var IN_RHINO = inRhino();
98 try
99 {
100 if (!IN_RHINO)
101 {
102 var a1=Array(0xFFFFFFFF);
103 a1.sort();
104 a1 = null;
105 }
107 var a2 = Array(0x40000000);
108 a2.sort();
109 a2=null;
111 var a3=Array(0x10000000/4);
112 a3.sort();
113 a3=null;
114 }
115 catch(ex)
116 {
117 // handle changed 1.9 branch behavior. see bug 422348
118 expect = 'InternalError: allocation size overflow';
119 actual = ex + '';
120 }
122 reportCompare(expect, actual, summary);
