445 bytes, text/html
1.64 KB, patch
Igor Bukanov: review+
Igor Bukanov: approval-branch-1.8.1+
|Details | Diff | Splinter Review|
1.40 KB, patch
|Details | Diff | Splinter Review|
2.47 KB, text/plain
2.47 KB, text/plain
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.
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.
(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?
this issue is similar to Bug 336409
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.
my macosx survives this test.
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?
(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 22.214.171.124 crashes, but macosx ppc continues normal operation.
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.
eventually may be a hardware problem - have you tried running memtest - some linux live cds include it.
Created attachment 225358 [details] [diff] [review] Proposed patch
Comment on attachment 225358 [details] [diff] [review] Proposed patch Nit: other places use (size_t)-1 as size_t max.
Fix checked into trunk.
Comment on attachment 225358 [details] [diff] [review] Proposed patch approved for 1.8.0 branch, a=dveditz for drivers
Fix checked into the 1.8 branches.
js1_5/Regress/regress-336410-1.js and js1_5/Regress/regress-336410-2.js windows shell crashes 126.96.36.199, 1.8.1, 1.9a1 windows/linux/mac crashes 188.8.131.52, 1.8.1, 1.9a1 I need someone who knows what is going to check this out.
this still crashes for me even on trunk, so this is not fixed.
(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.
removing fixed184.108.40.206, fixed1.8.1
Bug 336409 Comment #30 may help
Back to fixed, Blake says the remaining crash is actually bug 342960.
is it possible this bug to be invalid and all problems to have been caused by the arena?
I can't reproduce it on windows locally but I am showing crashes in browser tests for 220.127.116.11, 1.8.1a3 and 1.9a1 on windows/macppc/linux. Note that the String.toSource() bug is verified fixed on 18.104.22.168/1.9a1 but not on 1.8.1a3 so if these crashes on 22.214.171.124 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.
browser based js1_5/Regress/regress-336410-1.js, js1_5/Regress/regress-336410-2.js crashes on linux 20060707 builds for 126.96.36.199, 1.8.1 and 1.9. Since bug 342960 appears to be fixed for 188.8.131.52 and 1.9, it is not the cause of the crashes here. reopen and removed the fixed* keywords until someone tells me otherwise.
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.
per discussion with jay, marcia and dveditz: marking fixed and readding the fixed184.108.40.206 and fixed1.8.1 keywords.
filed Bug 344137
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
on linux get out of memory - trunk and branches
Created attachment 245291 [details] js1_5/Regress/regress-336410-1.js modify expected exit code for the shell per bug 358975.
Created attachment 245292 [details] js1_5/Regress/regress-336410-2.js modify expected exit code for the shell per bug 358975.
/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