418320 - Random Hangs when doing JavaScript

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[spam_hole]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020904 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020904 Minefield/3.0b4pre

Minefield 3.0b4 [built Feb 9th] randomly hangs, apparently due to JavaScript.

The CPU usage during any hang goes to 50% (100% on one CPU core), and according to Process Explorer, the bottom-most stack frame is
js3250.dll!js_SearchScope+0x69
though this varies with time; it's usually in js3250.dll, and it did go into a CycleCollector routine in another file at one point; however, I failed to copy that frame.

The hangs last a variable amount of time, anywhere from 5 seconds to several minutes. The amount of time is roughly proportional to the number of tabs open; with 10-15 tabs, Minefield may be stuck for 2-4 minutes.

Just now I had it hang for about 3 minutes, with only 3 tabs open, so I collected some stack information.

These functions appear commonly at the bottom of the thread stack (for the 100% CPU thread):
js3250.dll!js_PutCallObject+0x1266
js3250.dll!js_FindProperty+0x533
js3250.dll!JS_ArenaShutDown+0x2d05
js3250.dll!js_SearchScope+0x69

This is a stack sample:
ntkrnlpa.exe!ExAllocatePoolWithTag+0x96b
ntkrnlpa.exe!MmIsDriverVerifying+0xa30
hal.dll!HalClearSoftwareInterrupt+0x342
js3250.dll!js_Invoke+0xf3e
js3250.dll!JS_ArenaShutDown+0x2d05
js3250.dll!js_Invoke+0x4fe
js3250.dll!js_PutCallObject+0x1266

And another one from about 1 second later:
ntkrnlpa.exe!HalPrivateDispatchTable+0x17
js3250.dll!JS_ArenaShutDown+0x4c0
js3250.dll!js_ObjectOps

JS_ArenaShutDown does not appear in most of the stacks; I just happened to capture them here.

Reproducible: Sometimes

Steps to Reproduce:
1. Open GMail in several tabs (this by itself will make things slow, but this isn't the point)
2. Interact with each one (navigating is probably enough)
3. Close all the GMail tabs

With any luck, after several seconds/minutes, Minefield will hang.
Actual Results:  
Minefield hangs for some time, possibly not immediately after closing the tabs.

Expected Results:  
Minefield should not hang (it may pause while closing/opening tabs, but not outright hang)

I am using Firebug (beta), but disabling it does not solve the problem.

Comment 1

[spam_hole]

Problem improved with most recent nightly, maybe the nightly I used was broken. There are still periodic pauses, but nothing nearly as bad (I'll chalk the periodic pauses up to something completely different).

Comment 2

[timeless]

http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

feel free to read the windbg documentation for information about sampling, etc.

(note: you can setup process explorer to use the symbol server too if you like)

it sounds like you're just experiencing the cycle collector, which does happen periodically and is getting tuned.

Comment 3

[spam_hole]

Thanks. The problem has improved significantly with each trunk build, and I haven't encountered a major hang in about a week (still hangs for short periods of time occasionally, but nothing crippling).

I will trace with WinDbg if I get another hang. Thanks!

Comment 4

[spam_hole]

Got a major hang. I'm not sure if it's related to the posted bug, but before I could get a stack trace, Firefox ate all my memory and thrashed my system, forcing me to power cycle!

I rebooted, restored the session and it worked fine, up until a few minutes ago, when it began hanging for a long period of time. The memory usage went rampant, and I was forced to kill it without getting a stacktrace. On restarting Firefox/Minefield, it hung again, but I obtained a stack trace this time. It's huge, so it is attached.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032005 Minefield/3.0b5pre

From the looks of it, it's a JavaScript problem. The memory usage grew by about 16 MB/sec, and was at 1GB by the time I caught it. Firefox is behaving nice now, using only ~64MB with 13 tabs open.

Comment 5

[spam_hole]

Attachment: Large stack trace of recent hang.

Comment 6

[spam_hole]

Recent nightly is no longer usable (nightly as of today). Opening 20 tabs causes Minefield to enter the MarkSharpObjects recursion loop, allocating upwards of 2GB before a kill is required, since it begins mass swapping and thrashing at this point. I've upped the bug to blocker, and I'm posting this from Safari since Minefield is far too unstable at this point. Not sure what changes were made -- it looks a bit like a regression, but I can't tell for sure. I will attach another stack trace, this time including stack frames from the very beginning.

Comment 7

[spam_hole]

Attachment: Call stack of Minefield 3.0b5 while it allocates ~20MB/sec, quickly consuming 2GB+ of memory.

Comment 8

[timeless]

probably sessionstore

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

spam_hole, could you print script->filename in the top js_Interpret stack frame? It might also be useful to print *(JSClass *)(obj.fslots[2]-1) in the obj_toSource frame.

Comment 10

[spam_hole]

I think it might be sessionstore, since this bug usually manifests after starting FF (while all the tabs are reloading from last session). I can't get it to happen on the latest nightly, but then again, this bug was never particularly easy to trigger...

Comment 11

[aja+bugzilla]

Posting per Blake's request:
I encountered a startup hang last nite (updating from one hourly zip to next) involving restore of 20-25 sessions.  Unfortunately I didn't save the sessionstore db, but it did notice several console2 error messages, saying something like "excessive recursion" in sessionstore.js line 1896 (maybe it was NSIsessionstore.js or similar ???).  Didn't realize it was blown sessionstore db until I backed out to a couple prior hourlies that had been ok before which were now getting the same startup hangs.  

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

So, aja's error message, confirms that this is, in fact, session store (the file name you saw was nsSessionStore.js). The object in question is |oState| in:

    this._writeFile(this._sessionFile, oState.toSource());

which comes from:

    var oState = this._getCurrentState();

I'm not sure what state is contained in oState, so I'm not sure how deep an object graph we're expecting to see here...

Comment 13

[Mike Shaver (:shaver emeritus)]

See also 419661.

Comment 14

[Peter da Silva]

I'm not sure if this is related, but I am seeing frequent hangs in Camino with no really clear connection to any specific action. I actually had Camino hanging trying to enter my password at bugzilla.mozilla.org immediately after starting up!

Comment 15

[Stuart Morgan]

No, your proxy hang in Camino 1.6 is not even remotely related to a trunk-only JS bug. In the future, please sample hangs and either find an existing bug *based on the sample*, or file a new bug and let someone else dup it as necessary, rather than spamming a bunch of bugs that happen to be about hangs.

Comment 16

[spam_hole]

Recent builds have been variable; the one from April 22 was pretty terrible (hung a lot, also had some quirk with Firebug that completely prevented it from working), but the one I'm using now (2008042506) is quite stable -- I haven't had any hangs with it yet. Still, the fact that a relatively recent build had this issue suggests that it's something that's not quite resolved yet.

Comment 17

[Phoenix]

Is this still reproducible/actual?