293956 - shell can't display 2.0 * Number.MIN_VALUE

Status: RESOLVED FIXED

(Rhino Graveyard :: Core, defect, P5)

Description

[Stephen Weeks]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

Enter the statement "2.0 * Number.MIN_VALUE;" into the shell.
For the release I am running, Rhino 1.6 release 1 2004 11 30,
this causes the shell to go into a loop consuming lots of memory
(>800 meg) and printing nothing.


Reproducible: Always

Comment 1

[Igor Bukanov]

The bug is somewhere in org/mozilla/javascript/DToA.java which was translated 
from http://lxr.mozilla.org/mozilla/source/js/src/jsdtoa.c

Since SpiderMonkey does not show this bug, it should be possible to see where
the changes comes, but that is too much to spend :(

Comment 2

[Igor Bukanov]

Removal of accidental "fix".

Comment 3

[Attila Szegedi]

Okay, I emulated what shell does by feeding this snippet to a Java debugger:

Context cx = Context.enter();
System.out.println(Context.toString(cx.evaluateString(cx.initStandardObjects(), 
"(2.0 * Number.MIN_VALUE);", "", 1, null)));

Here's a short analysis:

DToA.pow5mult() is invoked with k=2147483647; (that is, Integer.MAX_VALUE), so 
it's struggling to calculate BigInteger.valueOf(5).pow(2147483647).

This value is passed from the local variable s5 in DToA.JS_dtoa. s5 got it from 
the local variable k in the same method. k got it as

k = (int)ds;

where ds is -4.847398702217033E298 (a number of pretty big magnitude). It is 
calculated as a certain linear combination of local variables d2 and i, d2 being 
-1.6742321987285427E299 (also a number of pretty big magnitude) and "i" being 
something I don't necessarily understand at a single reading of the code, but at 
least it has a much more tame value of 2. 

d2 is calculated by some direct bit operations on a double value -- there's lot 
of shifting, masking, and extracting of 32-bit subportions going on, so I guess 
something might get wrong there. As I said, I'm not seeing clearly at the moment 
what is that code doing... 

Maybe a Java oriented reimplementation of the spec from scratch would help. 
Also, it might be possible the algorithm is theoretically correct and would 
operate as expected if we'd have the patience to wait while it calculates 
5^2147483647 :-) /hint: not likely/

Comment 4

[Dan]

A few more datapoints for 1.6R2: if we replace 1.0 by 1.1, 3.0, 5.0, the bug
doesn't show up. For 2.1, 4.0, 10.0, it does.

Comment 5

[Dan]

I meant: if we replace 2.0 by such-and-such...

Comment 6

[Igor Bukanov]

Reassigning to [e-mail] pending resolution of bug 288433

Comment 7

[Norris Boyd]

Changing priority to P5 based on recent bug triage.

Comment 9

[Hannes Wallnoefer]

Another bug fixed by the commit for bug #548857!