JS console sucks down memory and CPU



Core Graveyard
Error Console
17 years ago
8 years ago


(Reporter: Keyser Sose, Assigned: Joe Hewitt (gone))


({helpwanted, memory-leak, perf})

helpwanted, memory-leak, perf

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
I discovered this bug while trying to figure out why the javascript menu's that 
worked in 0.9 arent working now. At some point or another I triggered a huge 
number of Alert that came continually with no letup into the Javascript 
 This slowly ate up the memory until Mozilla became very unresponsive and i 
finally had to kill the task. I was unable to get the bug to reproduce itself 
because of the complicated nature of the script but the problem remains.

  If someone was able to generate a large number of warnings repeaditly with no 
letup they could easily freeze or make Mozilla come to a crawl. This can be 
done from a *REMOTE WEBSITE* as well. This is very very bad so I decided to 
file this bug immmediately..

The best possible solution is to create an upper limit on the amount of memory 
the javascript console can take up...and if thats already done limit the number 
of alerts per time period etc.

ccing mstoltz@netscape.com


17 years ago
Keywords: hang

Comment 1

17 years ago
Alerts are supposed to be modal (and I think they are), so it's not possible to
have more than one at a time from the same window.  Window.open is another
story.  Any web site can open as many new windows as it wants.  This is true for
4x, IE, and probably Opera as well.  Maybe we want to do something about this,
maybe not.

Moving to DOM component to decide.
Assignee: jband → jst
Component: JavaScript Debugger → DOM Level 0
Keywords: hang
QA Contact: rginda → desale
There are lots of ways to make Mozilla unresponsive, and we really can't stop
them all. Sorry, but this just isn't something we can prevent right now. THe
best defense aginst denial of service is not to visit the offending site again.
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 3

17 years ago
Verified Wontfix.

Comment 4

17 years ago
If I remember correctly, the console is supposed to have a relatively small
circular buffer, which makes me wonder if there's some sort of leakage that's
happening.  It could also be that XUL is taking care of the content model for
stuff that's long since offscreen, and that outliner-ifying things would help.

Severity: critical → normal
Component: DOM Level 0 → XP Apps
Resolution: WONTFIX → ---
Summary: Remote Sites possibly able to Freeze/Hang or DoS Mozilla → JS console sucks down memory and CPU

Comment 5

17 years ago
Reassigning to jag, as I think it's more in his area.
Assignee: jst → jaggernaut

Comment 6

17 years ago
Still seeing this....it will fill up and continually loop forever. There is no 
way to stop it in addition to stop it sucking up memory as it grows larger and 
Build: 2001080904
Keywords: mlk, perf

Comment 7

17 years ago
Erh, no thanks.
Assignee: jaggernaut → pchen
QA Contact: desale → sairuh
QA Contact: sairuh → jrgm

Comment 8

17 years ago
nav triage team:

We probably want to figure out what's going wrong here but won't happen right
away. Marking p2, nsbeta1+, helpwanted, and mozilla1.0.1
Keywords: helpwanted, nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1


17 years ago
Blocks: 92580


17 years ago
No longer blocks: 92580

Comment 9

17 years ago
is bug 78179 is related or dupe? and should this bug be moved to JavaScript 
console ?
I think I've noticed this especially when I leave strict JS warninges enabled
and Chatzilla is running.  With the strict JS warnings CZ generates, it adds up.

I've got a testcase from something bzbarsky put together; basically a strict JS
warning generator.  It's supposed to generate 100 warnings; with strict JS
warning tracking enabled on my 56MB system, swapfile usage goes through the roof
and it can take over a minute to finish the test.  Personal experience shows the
performance hit lingers on after the test is complete.  Anyone interested in the

Comment 11

17 years ago
Sure, attach that testcase. Although this is pretty much a duplicate of 
bug 78179. 

I tried just having the JS Console refuse to append any rows to its widget,
but the JS Engine is still bogged down in handling the endless script warnings
generated on e.g., http://www.wocs.dk, from bug 78179. In other words, the 
defence for this has to come from where the messages are being generated; this
isn't really a case where building content in the UI is cause of the lockup.
Created attachment 59021 [details]
Testcase involving strict JS Warnings

The effect of this testcase is negligible unless you have strict JS warnings
enabled.  With them enabled... :-/
Rob: I know how you love strict-mode warnings... ;-)

Comment 14

17 years ago

Looks to me like we're supposed to wrap after 250 messages.  If someone else is
holding a reference to the messages (JS Console UI perhaps), the memory won't be

Someone could try changing |mBufferSize = 250;| to |mBufferSize = 2;|, and
disconnect the JS Console UI listener.  Memory should not grow substantially,
and performance should not be affected too much.  If it is, then someone is leaking.
Just out of curiousity, the three lines preceding line 63 in the above link seem
to indicate this should be a preference.  Is there one, and if so, what is it?
Incidentally, this bug and bug 104549 combine to generate a sizable performance
hit.  The sooner we get either one of these two bugs fixed, the better.

->JS Console
Assignee: pchen → hewitt
Component: XP Apps → JavaScript Console

Comment 18

17 years ago
I got clobbered this week by this bug.  Even after optimizing my script,
memory was continuously allocated and my routine never returned.  Running
without the console open fixed the problem.
To reproduce w/o strict mode, do a simple table sort with about 500 elements.
I cribbed my code from http://webfx.eae.net/dhtml/tablesort/tablesort.js
and cleaned it up so as to fetch the inner text only once before the sort,
and not during the sort in the compare (same with the cast).
The warning about el.innerText not existing throws Mozilla off in to the weeds.
Rick, e-mail me, please.  There are a couple optimizations we can do on your
script to kill those warnings.  Or see my tutorial on strict warnings, available
via link from http://www.javascriptkit.com .

Comment 20

11 years ago
When running the testcase in Firefox 3 beta 2 rc 1 on Windows XP with javascript.options.strict set to true, I get this output:

Without warnings: 2ms
With warnings: 3ms

Immediately after running the testcase, CPU does jump to about 20% for a fraction of a second, but I do not see any jump in memory use, even with Update Speed set to High in Windows Task Manager.

Can anyone reproduce this problem any more? If so, please attach a new testcase or provide a URL to reproduce.


11 years ago
Depends on: 78179


11 years ago
Last Resolved: 17 years ago11 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey


8 years ago
Component: Error Console → Error Console
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.