michael@0: // |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64/)||Android) -- No test results
michael@0: /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
michael@0: /* This Source Code Form is subject to the terms of the Mozilla Public
michael@0:  * License, v. 2.0. If a copy of the MPL was not distributed with this
michael@0:  * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
michael@0: 
michael@0: /*
michael@0:  *
michael@0:  * Date:    16 July 2002
michael@0:  * SUMMARY: Testing that Array.sort() doesn't crash on very large arrays
michael@0:  * See http://bugzilla.mozilla.org/show_bug.cgi?id=157652
michael@0:  *
michael@0:  * How large can a JavaScript array be?
michael@0:  * ECMA-262 Ed.3 Final, Section 15.4.2.2 : new Array(len)
michael@0:  *
michael@0:  * This states that |len| must be a a uint32_t (unsigned 32-bit integer).
michael@0:  * Note the UBound for uint32's is 2^32 -1 = 0xFFFFFFFF = 4,294,967,295.
michael@0:  *
michael@0:  * Check:
michael@0:  *              js> var arr = new Array(0xFFFFFFFF)
michael@0:  *              js> arr.length
michael@0:  *              4294967295
michael@0:  *
michael@0:  *              js> var arr = new Array(0x100000000)
michael@0:  *              RangeError: invalid array length
michael@0:  *
michael@0:  *
michael@0:  * We'll try the largest possible array first, then a couple others.
michael@0:  * We're just testing that we don't crash on Array.sort().
michael@0:  *
michael@0:  * Try to be good about memory by nulling each array variable after it is
michael@0:  * used. This will tell the garbage collector the memory is no longer needed.
michael@0:  *
michael@0:  * As of 2002-08-13, the JS shell runs out of memory no matter what we do,
michael@0:  * when trying to sort such large arrays.
michael@0:  *
michael@0:  * We only want to test that we don't CRASH on the sort. So it will be OK
michael@0:  * if we get the JS "out of memory" error. Note this terminates the test
michael@0:  * with exit code 3. Therefore we put
michael@0:  *
michael@0:  *                       |expectExitCode(3);|
michael@0:  *
michael@0:  * The only problem will arise if the JS shell ever DOES have enough memory
michael@0:  * to do the sort. Then this test will terminate with the normal exit code 0
michael@0:  * and fail.
michael@0:  *
michael@0:  * Right now, I can't see any other way to do this, because "out of memory"
michael@0:  * is not a catchable error: it cannot be trapped with try...catch.
michael@0:  *
michael@0:  *
michael@0:  * FURTHER HEADACHE: Rhino can't seem to handle the largest array: it hangs.
michael@0:  * So we skip this case in Rhino. Here is correspondence with Igor Bukanov.
michael@0:  * He explains that Rhino isn't actually hanging; it's doing the huge sort:
michael@0:  *
michael@0:  * Philip Schwartau wrote:
michael@0:  *
michael@0:  * > Hi,
michael@0:  * >
michael@0:  * > I'm getting a graceful OOM message on trying to sort certain large
michael@0:  * > arrays. But if the array is too big, Rhino simply hangs. Note that ECMA
michael@0:  * > allows array lengths to be anything less than Math.pow(2,32), so the
michael@0:  * > arrays I'm sorting are legal.
michael@0:  * >
michael@0:  * > Note below, I'm getting an instantaneous OOM error on arr.sort() for LEN
michael@0:  * > = Math.pow(2, 30). So shouldn't I also get one for every LEN between
michael@0:  * > that and Math.pow(2, 32)? For some reason, I start to hang with 100% CPU
michael@0:  * > as LEN hits, say, Math.pow(2, 31) and higher. SpiderMonkey gives OOM
michael@0:  * > messages for all of these. Should I file a bug on this?
michael@0:  *
michael@0:  *   Igor Bukanov wrote:
michael@0:  *
michael@0:  * This is due to different sorting algorithm Rhino uses when sorting
michael@0:  * arrays with length > Integer.MAX_VALUE. If length can fit Java int,
michael@0:  * Rhino first copies internal spare array to a temporary buffer, and then
michael@0:  * sorts it, otherwise it sorts array directly. In case of very spare
michael@0:  * arrays, that Array(big_number) generates, it is rather inefficient and
michael@0:  * generates OutOfMemory if length fits int. It may be worth in your case
michael@0:  * to optimize sorting to take into account array spareness, but then it
michael@0:  * would be a good idea to file a bug about ineficient sorting of spare
michael@0:  * arrays both in case of Rhino and SpiderMonkey as SM always uses a
michael@0:  * temporary buffer.
michael@0:  *
michael@0:  */
michael@0: //-----------------------------------------------------------------------------
michael@0: var BUGNUMBER = 157652;
michael@0: var summary = "Testing that Array.sort() doesn't crash on very large arrays";
michael@0: var expect = 'No Crash';
michael@0: var actual = 'No Crash';
michael@0: 
michael@0: printBugNumber(BUGNUMBER);
michael@0: printStatus(summary);
michael@0: 
michael@0: expectExitCode(0);
michael@0: expectExitCode(5);
michael@0: 
michael@0: var IN_RHINO = inRhino();
michael@0: 
michael@0: try
michael@0: {
michael@0:   if (!IN_RHINO)
michael@0:   {
michael@0:     var a1=Array(0xFFFFFFFF);
michael@0:     a1.sort();
michael@0:     a1 = null;
michael@0:   }
michael@0: 
michael@0:   var a2 = Array(0x40000000);
michael@0:   a2.sort();
michael@0:   a2=null;
michael@0: 
michael@0:   var a3=Array(0x10000000/4);
michael@0:   a3.sort();
michael@0:   a3=null;
michael@0: }
michael@0: catch(ex)
michael@0: {
michael@0:   // handle changed 1.9 branch behavior. see bug 422348
michael@0:   expect = 'InternalError: allocation size overflow';
michael@0:   actual = ex + '';
michael@0: }
michael@0: 
michael@0: reportCompare(expect, actual, summary);