160531 - xpcshell, browser corrupt display of certain integers

Status: RESOLVED DUPLICATE of bug 140852

(Core :: DOM: Core & HTML, defect)

Description

[Brian Kukwa]

When passing an integer through a method, the integer passes corrupt data. For
example, if 1000100019 is the intended variable to be passed, 100010018.: is
passed. The integer is decreased by one, followed by a dot and colon. This can
be replicated everytime when multiple calls to the method are called on the same
page.

1.call the submitAction(String var1,String var2,integer int1)
2.alert(int1)
3.corrupt data is displayed


This page can only be referenced by logging in. I've found a fix to this by
passing a String as the third parameter. The method declaration would look like
submitAction(String,String,String), instead of submitAction(String,String,Integer).

Example code:

submitAction(strForm,strAction,intAccount)
{
	var oForm = eval('document.'+strForm);
	
	oForm.srhFormAction.value=strAction;
        alert('val is: '+intAccount);
	oForm.nrvAccountNumber.value=intAccount;
	alert('val is: '+oForm.nrvAccountNumber.value);
	//oForm.submit();
}

An interesting note is that the corrupt data is always subtracting one from the
oringal value.

I've verified that Netscape and Internet Explorer work with the integer as the
third parameter. If you need any additional information, feel free to email.

Comment 1

[Daniel Wang]

WORKSFORME moz 2002072104 win98

Comment 2

[Brian Kukwa]

Attachment: This is the html/javascript that breaks.

Click on 100010016614 to see the pop up window. Notice the difference in
numbers, plus the dot and colon. The build I tested this with is 2002072104.

Comment 3

[Alfonso Martinez]

a more direct test: 

javascript:alert(100000000000);
javascript:alert(900000000000);

Comment 4

[Brian Kukwa]

Attachment: I've subracted all of the other garbage html to get to the core of the situation.

This is the exact code that is breaking on build 2002072104. I am not placing
any dots or colons inside of the call to the method.

Comment 5

[[e-mail]]

Attachment: testcase

this one works by clicking on it. It is interesting, that the larger number is
not currupted whereas the smaller is. This seems to rule out a simple overflow.

Comment 6

[[e-mail]]

bug confirmed on build 2002072508 on winxp, changing status to NEW, setting
severity major

Comment 7

[Phil Schwartau]

I tried the testcase in the standalone JS shell, replacing alert()
with print(), and got no error:

     print(100010016614) ---> '100010016614'
     print(900000000000) ---> '900000000000'

But in the browser, alert() produces the error described above.
Therefore it is some problem specific to alert().

Reassigning to DOM Level 0. This is a duplicate of another 
DOM bug, but I can't seem to find it at the moment -

Comment 8

[Phil Schwartau]

*** Bug 161046 has been marked as a duplicate of this bug. ***

Comment 9

[Phil Schwartau]

The behavior noted in the duplicate bug 161046 has to do with 
parseFloat() and not alert(). As with this bug, it seems not to
happen in the JS shell, but only in the xpcshell or browser:


---------------------- IN OPTIMIZED JS SHELL -----------------------
js> num = "[phone]"
[phone]

js> parseFloat(num);
441111111111


--------------------------  IN XPCSHELL  ---------------------------
js> num = "[phone]"
[phone]

js> parseFloat(num);
441111111110.:   <<<-------------------------- here is the corruption



Thus changing summary from 

         "alert() corrupts display of certain integers"
     to  "xpcshell, browser corrupt display of certain integers"



NOTE:

1. I am only seeing this on Windows, and not on Mac9.1 or Linux
2. I see it in Mozilla WinNT at least all the way back to 2002-04-28
3. I do not see it in Mozilla WinNT 2002-04-22.
4. So: due to a checkin between 2002-04-22 and 2002-04-28 ?


Again, I think this may be a duplicate of another report, but 
I can't find it yet -

Comment 10

[Phil Schwartau]

I notice a checkin to jsdtoa.c on 2002-04-24:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&fi
le=jsdtoa.c&root=/cvsroot&subdir=mozilla/js/src&command=DIFF_FRAMESET&rev1=3.16&
rev2=3.17

That fits into the timeframe outlined in the above comment, but
I don't know if it could be the cause. cc'ing rogerl, khanson,
[e-mail], [e-mail] for advice

Again, is only happening in the xpcshell and browser on Windows,
not in the JS optimized shell on Windows, and not in the browser
on Mac9.1 or Linux.

I'm not sure if the options I use to build the JS shell match those
used in building the xpcshell or browser, so perhaps that is a 
factor to consider -

Comment 11

[Steven Cole]

Hmmm.  The change you found, Phil, is the fix for bug 138666.  I think it's very
unlikely that this is the cause of the problem, especially since the code
modification for that bug should cause the same change in behavior for both
jsshell and xpcshell.

Can you recompile with a April 23, 2002 jsdtoa.c and see what happens?  I
suspect the bug will still be there, pointing the finger of blame away from
jsdtoa.c.  (I don't have a functional mozilla build environment here; we just do
jsshell and our Spidermonkey embedding here [neither of which have this problem]
--- so I don't get xpcshell...)

--scole

Comment 12

[Kenton Hanson (gone)]

I vaguely remember this problem.  It behaves like an integer being stored in a
floating-point type with 30 bits of significand.  Integers stored in double
precision don’t suffer from this problem.  I agree with Phil comment #9, this is
in a recent (6 to 12 months) bug report that was resolved.

Comment 13

[Steven Cole]

Possible dup of bug 140852?  --scole

Comment 14

[Kenton Hanson (gone)]

The recent bug 136100 was caused by an error in the underlying arithmetic of an
ARM [gcc compiler bug].  This bug appears to be similar, a loss of precison
caused by a shorter than doube precison type. 

Comment 15

[Phil Schwartau]

Kenton, Steven: thanks! Bug 140852 I was thinking of. I'm going to 
go ahead and dupe this bug against that one, and copy comments 
made here over to it -

*** This bug has been marked as a duplicate of 140852 ***