1/* ***** BEGIN LICENSE BLOCK ***** 2* Version: NPL 1.1/GPL 2.0/LGPL 2.1 3* 4* The contents of this file are subject to the Netscape Public License 5* Version 1.1 (the "License"); you may not use this file except in 6* compliance with the License. You may obtain a copy of the License at 7* http://www.mozilla.org/NPL/ 8* 9* Software distributed under the License is distributed on an "AS IS" basis, 10* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License 11* for the specific language governing rights and limitations under the 12* License. 13* 14* The Original Code is JavaScript Engine testing utilities. 15* 16* The Initial Developer of the Original Code is Netscape Communications Corp. 17* Portions created by the Initial Developer are Copyright (C) 2002 18* the Initial Developer. All Rights Reserved. 19* 20* Contributor(s): zen-parse@gmx.net, pschwartau@netscape.com 21* 22* Alternatively, the contents of this file may be used under the terms of 23* either the GNU General Public License Version 2 or later (the "GPL"), or 24* the GNU Lesser General Public License Version 2.1 or later (the "LGPL"), 25* in which case the provisions of the GPL or the LGPL are applicable instead 26* of those above. If you wish to allow use of your version of this file only 27* under the terms of either the GPL or the LGPL, and not to allow others to 28* use your version of this file under the terms of the NPL, indicate your 29* decision by deleting the provisions above and replace them with the notice 30* and other provisions required by the GPL or the LGPL. If you do not delete 31* the provisions above, a recipient may use your version of this file under 32* the terms of any one of the NPL, the GPL or the LGPL. 33* 34* ***** END LICENSE BLOCK ***** 35* 36* 37* Date: 16 July 2002 38* SUMMARY: Testing that Array.sort() doesn't crash on very large arrays 39* See http://bugzilla.mozilla.org/show_bug.cgi?id=157652 40* 41* How large can a JavaScript array be? 42* ECMA-262 Ed.3 Final, Section 15.4.2.2 : new Array(len) 43* 44* This states that |len| must be a a uint32 (unsigned 32-bit integer). 45* Note the UBound for uint32's is 2^32 -1 = 0xFFFFFFFF = 4,294,967,295. 46* 47* Check: 48* js> var arr = new Array(0xFFFFFFFF) 49* js> arr.length 50* 4294967295 51* 52* js> var arr = new Array(0x100000000) 53* RangeError: invalid array length 54* 55* 56* We'll try the largest possible array first, then a couple others. 57* We're just testing that we don't crash on Array.sort(). 58* 59* Try to be good about memory by nulling each array variable after it is 60* used. This will tell the garbage collector the memory is no longer needed. 61* 62* As of 2002-08-13, the JS shell runs out of memory no matter what we do, 63* when trying to sort such large arrays. 64* 65* We only want to test that we don't CRASH on the sort. So it will be OK 66* if we get the JS "out of memory" error. Note this terminates the test 67* with exit code 3. Therefore we put 68* 69* |expectExitCode(3);| 70* 71* The only problem will arise if the JS shell ever DOES have enough memory 72* to do the sort. Then this test will terminate with the normal exit code 0 73* and fail. 74* 75* Right now, I can't see any other way to do this, because "out of memory" 76* is not a catchable error: it cannot be trapped with try...catch. 77* 78* 79* FURTHER HEADACHE: Rhino can't seem to handle the largest array: it hangs. 80* So we skip this case in Rhino. Here is correspondence with Igor Bukanov. 81* He explains that Rhino isn't actually hanging; it's doing the huge sort: 82* 83* Philip Schwartau wrote: 84* 85* > Hi, 86* > 87* > I'm getting a graceful OOM message on trying to sort certain large 88* > arrays. But if the array is too big, Rhino simply hangs. Note that ECMA 89* > allows array lengths to be anything less than Math.pow(2,32), so the 90* > arrays I'm sorting are legal. 91* > 92* > Note below, I'm getting an instantaneous OOM error on arr.sort() for LEN 93* > = Math.pow(2, 30). So shouldn't I also get one for every LEN between 94* > that and Math.pow(2, 32)? For some reason, I start to hang with 100% CPU 95* > as LEN hits, say, Math.pow(2, 31) and higher. SpiderMonkey gives OOM 96* > messages for all of these. Should I file a bug on this? 97* 98* Igor Bukanov wrote: 99* 100* This is due to different sorting algorithm Rhino uses when sorting 101* arrays with length > Integer.MAX_VALUE. If length can fit Java int, 102* Rhino first copies internal spare array to a temporary buffer, and then 103* sorts it, otherwise it sorts array directly. In case of very spare 104* arrays, that Array(big_number) generates, it is rather inefficient and 105* generates OutOfMemory if length fits int. It may be worth in your case 106* to optimize sorting to take into account array spareness, but then it 107* would be a good idea to file a bug about ineficient sorting of spare 108* arrays both in case of Rhino and SpiderMonkey as SM always uses a 109* temporary buffer. 110* 111*/ 112//----------------------------------------------------------------------------- 113var bug = 157652; 114var summary = "Testing that Array.sort() doesn't crash on very large arrays"; 115 116printBugNumber(bug); 117printStatus(summary); 118 119// JSC doesn't run out of memory, so we don't expect an abnormal exit code 120//expectExitCode(3); 121var IN_RHINO = inRhino(); 122 123if (!IN_RHINO) 124{ 125 var a1=Array(0xFFFFFFFF); 126 a1.sort(); 127 a1 = null; 128} 129 130var a2 = Array(0x40000000); 131a2.sort(); 132a2=null; 133 134var a3=Array(0x10000000/4); 135a3.sort(); 136a3=null; 137