463842 - Browser eats up all my memory (and more?) on http://l10n.mozilla.org/dashboard/

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Robert Kaiser]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081108 SeaMonkey/2.0a2pre

When I load http://l10n.mozilla.org/dashboard/ in my current trunk builds from today, it locks up UI, uses all CPU it can get and starts eating up more and more memory, once RAM is full it eats swap to the limits, I suspect it wants even more - I manually killed one process at 3 GB of virtual memory size (I have 2 GB RAM).
My current Minefield build (Linux) does the same, yesterday's builds worked fine (don't have exact ID/time, sorry).

I have no clue what is actually causing this, but this is a JS-heavy site and TraceMonkey stuff is the biggest thing I saw landing since yesterday, so I try blaming JS for now :p

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre ID:20081108033239

javascript.options.jit.content;false circumvents the issue, of course.
prolly on of the static.simile.mit.edu JS' causes this.

Comment 2

[Robert Kaiser]

Right, the same build with TraceMonkey off works fine.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Dupe of bug 463814?

Comment 4

[Axel Hecht [:Pike]]

This is dogfood for the l10n community. Trying to put this on the b2 triage list.

I'll try to kick off a tryserver build with the patch in bug 463814.

Comment 5

[Axel Hecht [:Pike]]

I tested the mac tryserver build on https://build.mozilla.org/tryserver-builds/2008-11-10_05:[e-mail]-try-6ac87a7f420/, and it doesn't fix this issue.

If the patch in bug 463814 is right, this is not a dupe.

Comment 6

[Axel Hecht [:Pike]]

I did a little debugging, which apparently confused me, maybe it adds help to others. While it's bloating away, I did a ctrl-c, and then

(gdb) bt
#1  0x001e2022 in NewGCChunk () at /Users/axelhecht/src/central/mozilla-central/js/src/jsgc.cpp:802
#2  0x001e20f1 in NewGCArena (rt=0x850200) at /Users/axelhecht/src/central/mozilla-central/js/src/jsgc.cpp:922
#3  0x001e513b in js_NewGCThing (cx=0xc8f400, flags=0, nbytes=32) at /Users/axelhecht/src/central/mozilla-central/js/src/jsgc.cpp:1898
#4  0x001b8681 in js_FastNewArray (cx=0xc8f400, proto=0x1bd45920) at /Users/axelhecht/src/central/mozilla-central/js/src/jsarray.cpp:3056
#5  0x160783bd in ?? () at xpcprivate.h:2580
#6  0x00273f77 in js_ExecuteTree (cx=0x79be4000, f=0x0, inlineCallCount=@0xbfffa3fc, innermostNestedGuardp=0xbfffcf9c) at /Users/axelhecht/src/central/mozilla-central/js/src/jstracer.cpp:3274
#7  0x00287c44 in js_MonitorLoopEdge (cx=0xc8f400, inlineCallCount=@0xbfffd3dc) at /Users/axelhecht/src/central/mozilla-central/js/src/jstracer.cpp:3560
#8  0x0020b7a4 in js_Interpret (cx=0xc8f400) at /Users/axelhecht/src/central/mozilla-central/js/src/jsinterp.cpp:3657

(gdb) frame 6
#6  0x00273f77 in js_ExecuteTree (cx=0x79be4000, f=0x0, inlineCallCount=@0xbfffa3fc, innermostNestedGuardp=0xbfffcf9c) at /Users/axelhecht/src/central/mozilla-central/js/src/jstracer.cpp:3274
3274	               VMSideExit** innermostNestedGuardp)
(gdb) p f
$1 = (class nanojit::Fragment *) 0x0
(gdb) up
#7  0x00287c44 in js_MonitorLoopEdge (cx=0xc8f400, inlineCallCount=@0xbfffd3dc) at /Users/axelhecht/src/central/mozilla-central/js/src/jstracer.cpp:3560
3560	    lr = js_ExecuteTree(cx, match, inlineCallCount, &innermostNestedGuard);
(gdb) p match
$2 = <variable optimized away by compiler>


I'm not sure if the optimizations are the real problem, or just confusing the debugger.

Comment 8

[juan becerra [:juanb]]

Attachment: dialog that appeared at some point (from another user)

Comment 9

[(mostly gone) XtC4UaLL [:xtc4uall]]

this is WFM/FIXED using TM-hourly ID:20081113040854 (http://hg.mozilla.org/tracemonkey/rev/f9e244da246d). so after the merge it should be ok in today's MC nightly.

Comment 10

[Axel Hecht [:Pike]]

Yes, fixed in today's nightly with revision http://hg.mozilla.org/mozilla-central/rev/85fbe5bd09c8. Virtual dupe of whatever fixed this as part of the last tracemonkey merge.

Comment 11

[Robert Kaiser]

Verified on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081116 Lightning/1.0pre SeaMonkey/2.0a2pre