336410 - probably an integer overflow in array_toSource

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[georgi - hopefully not receiving bugspam]

there is probably an integer overflow in array_toSource  :
var o=[r, r, r, r, r, r, r, r, r];

var rr=o.toSource();

where r occupies 512MB

causes this crash:
#0  0xffffe410 in ?? ()
#1  0xbf82364c in ?? ()
#2  0xb740cff4 in ?? () from /lib/tls/libc.so.6
#3  0xbf823638 in ?? ()
#4  0xb73717b6 in nanosleep () from /lib/tls/libc.so.6
#5  0xb73715df in sleep () from /lib/tls/libc.so.6
#6  0xb7eae96b in ah_crap_handler (signum=11) at nsSigHandlers.cpp:133
#7  0xb7ec6cc4 in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileLock.cpp:210
#8  <signal handler called>
#9  0xb7dceba5 in QuoteString (sp=0xbf823a98, str=0x87654a8, quote=34)
    at /opt/joro/firefox/mozilla/js/src/jsopcode.c:438
#10 0xb7dced6c in js_QuoteString (cx=0x875c720, str=0x87654a8, quote=34)
    at /opt/joro/firefox/mozilla/js/src/jsopcode.c:496
#11 0xb7e015d2 in js_ValueToSource (cx=0x875c720, v=141972652)
    at /opt/joro/firefox/mozilla/js/src/jsstr.c:2697
#12 0xb7d65d2c in array_join_sub (cx=0x875c720, obj=0x87654a0, op=TO_SOURCE, 
    sep=0x0, rval=0xbf823c98) at /opt/joro/firefox/mozilla/js/src/jsarray.c:510
#13 0xb7d660e1 in array_toSource (cx=0x875c720, obj=0x87654a0, argc=0, 
    argv=0x89228dc, rval=0xbf823c98)
    at /opt/joro/firefox/mozilla/js/src/jsarray.c:592
#14 0xb7d9b00a in js_Invoke (cx=0x875c720, argc=0, flags=0)

memory usage is about 600MB and probably can be made smaller.

Comment 1

[georgi - hopefully not receiving bugspam]

Attachment: crash

Comment 2

[Daniel Veditz [:dveditz]]

Is this x86_64 Linux running 32-bit Firefox as in bug 335535? Asking in case it's relevant. Don't see a problem (beyond the temporary busy-script freeze) in 32-bit windows.

Comment 3

[georgi - hopefully not receiving bugspam]

(In reply to comment #2)
> Is this x86_64 Linux running 32-bit Firefox as in bug 335535? Asking in case
> it's relevant. Don't see a problem (beyond the temporary busy-script freeze) in
> 32-bit windows.
> 

according to me this is pure 32 bit issue. i crash on 32 bit linux and 32 bit
macosx ppc with the same stack.

do you get out of memory error?

Comment 4

[georgi - hopefully not receiving bugspam]

this issue is similar to Bug 336409

Comment 5

[Bob Clary [:bc] (inactive)]

Attachment: js1_5/Regress/regress-336410-1.js (96M)

Comment 6

[Bob Clary [:bc] (inactive)]

Attachment: js1_5/Regress/regress-336410-2.js (128M)

Comment 7

[Bob Clary [:bc] (inactive)]

fwiw, the test for this bug killed either Mac OS X or the VNC server I use to access the boxes. I will be temporarily adding it to my list of tests excluded from the automated runs until it is fixed across 1.8.0, 1.8, 1.9.

Comment 8

[georgi - hopefully not receiving bugspam]

my macosx survives this test.

Comment 9

[Bob Clary [:bc] (inactive)]

I managed to kill two different Mac OS X boxes using the browser versions of the tests. Did you just run the shell based tests?

Comment 10

[georgi - hopefully not receiving bugspam]

(In reply to comment #9)
> I managed to kill two different Mac OS X boxes using the browser versions of
> the tests. Did you just run the shell based tests?
> 

local browser version of copy of my testscase and a little modified (changed print.. to alert() ) of the 128M testcase in this bug.

firefox 1.5.0.3 crashes, but macosx ppc continues normal operation.

Comment 11

[Bob Clary [:bc] (inactive)]

Ok, then I guess that answers the question about whether the problem was with the machine as a whole or just with the VNC server. 

Comment 12

[georgi - hopefully not receiving bugspam]

eventually may be a hardware problem - have you tried running memtest - some linux live cds include it.

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed patch

Comment 14

[Igor Bukanov]

Comment on attachment 225358 [details] [diff] [review]
Proposed patch

Nit: other places use (size_t)-1 as size_t max.

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 225358 [details] [diff] [review]
Proposed patch

approved for 1.8.0 branch, a=dveditz for drivers

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into the 1.8 branches.

Comment 18

[Bob Clary [:bc] (inactive)]

js1_5/Regress/regress-336410-1.js and js1_5/Regress/regress-336410-2.js
windows shell crashes 1.8.0.5, 1.8.1, 1.9a1
windows/linux/mac crashes 1.8.0.5, 1.8.1, 1.9a1

I need someone who knows what is going to check this out.

Comment 19

[georgi - hopefully not receiving bugspam]

this still crashes for me even on trunk, so this is not fixed.

Comment 20

[georgi - hopefully not receiving bugspam]

(In reply to comment #11)
> Ok, then I guess that answers the question about whether the problem was with
> the machine as a whole or just with the VNC server. 
> 

this started to kill my macosx with a spinning wheel, but unusable UI (though the kernel is alive). a reason for this may be applying apple's updates.

Comment 21

[Bob Clary [:bc] (inactive)]

removing fixed1.8.0.5, fixed1.8.1

Comment 22

[georgi - hopefully not receiving bugspam]

Bug 336409 Comment #30 may help

Comment 23

[Daniel Veditz [:dveditz]]

Back to fixed, Blake says the remaining crash is actually bug 342960.

Comment 24

[georgi - hopefully not receiving bugspam]

is it possible this bug to be invalid and all problems to have been caused by
the arena?

Comment 25

[Bob Clary [:bc] (inactive)]

I can't reproduce it on windows locally but I am showing crashes in browser
tests for 1.8.0.5, 1.8.1a3 and 1.9a1 on windows/macppc/linux. Note that the
String.toSource() bug is verified fixed on 1.8.0.5/1.9a1 but not on 1.8.1a3 so
if these crashes on 1.8.0.5 and 1.9a1 are real then they are _not bug 342960_.
I'll know more hopefully with today's builds. leaving fixed status alone for
now.

Comment 26

[Bob Clary [:bc] (inactive)]

browser based js1_5/Regress/regress-336410-1.js,
js1_5/Regress/regress-336410-2.js crashes on linux 20060707 builds for 1.8.0.5,
1.8.1 and 1.9. Since bug 342960 appears to be fixed for 1.8.0.5 and 1.9, it is
not the cause of the crashes here.

reopen and removed the fixed* keywords until someone tells me otherwise.

Comment 27

[georgi - hopefully not receiving bugspam]

on today linux trunk i don't crash with my testcase after 8 reloads.

valgrind seems unusable in this case because it takes at least 4 hours.

Comment 28

[Bob Clary [:bc] (inactive)]

per discussion with jay, marcia and dveditz: marking fixed and readding the fixed1.8.0.5 and fixed1.8.1 keywords.

Comment 29

[Bob Clary [:bc] (inactive)]

filed Bug 344137

Comment 30

[Alexander Sack]

Attachment: for 1.0.x

Comment 31

[Bob Clary [:bc] (inactive)]

1.8, 1.9 windows, mac* do not crash on either testcase. 1.8, 1.9 linux all exit on the test farm with SIGABRT, but I can't reproduce it locally or on the qa farm machines. Whatever the situation it is not this bug, so I will verify.

verify fixed 1.8, 1.9

Comment 32

[georgi - hopefully not receiving bugspam]

on linux get out of memory - trunk and branches

Comment 33

[Bob Clary [:bc] (inactive)]

Attachment: js1_5/Regress/regress-336410-1.js

modify expected exit code for the shell per bug 358975.

Comment 34

[Bob Clary [:bc] (inactive)]

Attachment: js1_5/Regress/regress-336410-2.js

modify expected exit code for the shell per bug 358975.

Comment 35

[Bob Clary [:bc] (inactive)]

/cvsroot/mozilla/js/tests/js1_5/extensions/regress-336410-1.js,v  <--  regress-336410-1.js

/cvsroot/mozilla/js/tests/js1_5/extensions/regress-336410-2.js,v  <--  regress-336410-2.js

moved to extensions/ since they use toSource