The Tor Browser / file comparison
comparison: js/src/tests/js1_5/Array/regress-157652.js
js/src/tests/js1_5/Array/regress-157652.js
- branch
- TOR_BUG_9701
- changeset 15
- b8a032363ba2
equal
deleted
inserted
replaced
| -1:000000000000 | 0:e1fbe2018131 |
|---|---|
| 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/. */ | |
| 6 | |
| 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'; | |
| 89 | |
| 90 printBugNumber(BUGNUMBER); | |
| 91 printStatus(summary); | |
| 92 | |
| 93 expectExitCode(0); | |
| 94 expectExitCode(5); | |
| 95 | |
| 96 var IN_RHINO = inRhino(); | |
| 97 | |
| 98 try | |
| 99 { | |
| 100 if (!IN_RHINO) | |
| 101 { | |
| 102 var a1=Array(0xFFFFFFFF); | |
| 103 a1.sort(); | |
| 104 a1 = null; | |
| 105 } | |
| 106 | |
| 107 var a2 = Array(0x40000000); | |
| 108 a2.sort(); | |
| 109 a2=null; | |
| 110 | |
| 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 } | |
| 121 | |
| 122 reportCompare(expect, actual, summary); |
