81279 - JS console sucks down memory and CPU

Status: RESOLVED WORKSFORME

(Core Graveyard :: Error Console, defect, P2)

Description

[Keyser Sose]

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 
Console..
 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 [e-mail]

Comment 1

[Robert Ginda]

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.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 3

[Prashant Desale]

Verified Wontfix.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Reassigning to jag, as I think it's more in his area.

Comment 6

[Keyser Sose]

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 
larger.
Build: 2001080904

Comment 7

[jag (Peter Annema)]

Erh, no thanks.

Comment 8

[Paul Chen]

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

Comment 9

[Henrik Gemal]

is bug 78179 is related or dupe? and should this bug be moved to JavaScript 
console ?

Comment 10

[Alex Vincent [:WeirdAl]]

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
testcase?

Comment 11

[John Morrison]

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.

Comment 12

[Alex Vincent [:WeirdAl]]

Attachment: Testcase involving strict JS Warnings

The effect of this testcase is negligible unless you have strict JS warnings
enabled.  With them enabled... :-/

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

Rob: I know how you love strict-mode warnings... ;-)

Comment 14

[Robert Ginda]

http://lxr.mozilla.org/mozilla/source/xpcom/base/nsConsoleService.cpp#63

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
reclaimed.

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.

Comment 15

[Alex Vincent [:WeirdAl]]

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?

Comment 16

[Alex Vincent [:WeirdAl]]

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.

Comment 17

[Christopher Aillon (sabbatical, not receiving bugmail)]

->JS Console

Comment 18

[Rick DeBay]

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.

Comment 19

[Alex Vincent [:WeirdAl]]

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

[Steve Chapel]

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.