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

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