xpcshell, browser corrupt display of certain integers

RESOLVED DUPLICATE of bug 140852

Status

()

Core
DOM: Core & HTML
--
major
RESOLVED DUPLICATE of bug 140852
16 years ago
16 years ago

People

(Reporter: Brian Kukwa, Assigned: jst)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
WORKSFORME moz 2002072104 win98
(Reporter)

Comment 2

16 years ago
Created attachment 93578 [details]
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

16 years ago
a more direct test: 

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

Comment 4

16 years ago
Created attachment 93580 [details]
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.
Attachment #93578 - Attachment is obsolete: true
Created attachment 93582 [details]
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.
Attachment #93580 - Attachment is obsolete: true
bug confirmed on build 2002072508 on winxp, changing status to NEW, setting
severity major
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: JavaScript method passing corupt integer → JavaScript method passing corrupt integer

Comment 7

16 years ago
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 -

Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale
Summary: JavaScript method passing corrupt integer → alert() corrupts display of certain integers

Comment 8

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

Comment 9

16 years ago
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 = "+441111111111"
+441111111111

js> parseFloat(num);
441111111111


--------------------------  IN XPCSHELL  ---------------------------
js> num = "+441111111111"
+441111111111

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 -
Summary: alert() corrupts display of certain integers → xpcshell, browser corrupt display of certain integers

Comment 10

16 years ago
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,
scole@planetweb.com, bratell@lysator.liu.se 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

16 years ago
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

16 years ago
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

16 years ago
Possible dup of bug 140852?  --scole

Comment 14

16 years ago
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

16 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.