tests/mozilla/js1_5/Array/regress-157652.js

   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 //-----------------------------------------------------------------------------
 113 var bug = 157652;
 114 var summary = "Testing that Array.sort() doesn't crash on very large arrays";
 115
 116 printBugNumber(bug);
 117 printStatus(summary);
 118
 119 // KJS doesn't run out of memory, so we don't expect an abnormal exit code
 120 //expectExitCode(3);
 121 var IN_RHINO = inRhino();
 122
 123 if (!IN_RHINO)
 124 {
 125   var a1=Array(0xFFFFFFFF);
 126   a1.sort();
 127   a1 = null;
 128 }
 129
 130 var a2 = Array(0x40000000);
 131 a2.sort();
 132 a2=null;
 133
 134 var a3=Array(0x10000000/4);
 135 a3.sort();
 136 a3=null;