tor-browser

The Tor Browser
git clone https://git.dasho.dev/tor-browser.git
Log | Files | Refs | README | LICENSE

regress-157652.js (4243B)

      1 // |reftest| skip-if(is64Bit||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 try
     97 {
     98  var a1=Array(0xFFFFFFFF);
     99  a1.sort();
    100  a1 = null;
    101 
    102  var a2 = Array(0x40000000);
    103  a2.sort();
    104  a2=null;
    105 
    106  var a3=Array(0x10000000/4);
    107  a3.sort();
    108  a3=null;
    109 }
    110 catch(ex)
    111 {
    112  // handle changed 1.9 branch behavior. see bug 422348
    113  expect = 'InternalError: allocation size overflow';
    114  actual = ex + '';
    115 }
    116 
    117 reportCompare(expect, actual, summary);