905459 - Many leaked windows followed by a crash when editing items at innovateistore.com; maybe due to stack exhaustion?

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Justin Lebar (not reading bugmail)]

This is a weird bug; bear with me.

My dad has an online store, innovateistore.com.  He's found that if he does a lot of editing of the content of this store, his browser gradually slows down, eats up a lot of memory, and eventually crashes.

He's using FF22 on Windows 7.  I think it's x64.  I'm waiting to hear if this reproduces on nightly.  The only extension he has is ABP.

I have an about:memory report, a gc log, and an all-traces cc log captured after adding many items to the store, then closing all tabs and minimizing memory usage.  I don't want to post them to the bug because they almost surely contain private data (strings and so on), but I'm happy to make them available to anyone who's signed an NDA with Mozilla.

The about:memory report I have shows 160+ ghost windows, so something is clearly up.  The ghost windows are for innovateistore.com, but also for gmail, so maybe this bug has nothing to do with the site itself.

mccr8 and I have analyzed the gc/cc logs, and I'll post this analysis below (I have to re-create it).  But what we saw was that at least a few windows were being held alive via a string.  The string's prototype had a function added to it (presumably by content), and the function entrained the window.

We don't know where this string comes from; it's notated as "(null)" in the GC log.  But it is possible that it's a stack variable; the string appears near the beginning of the log (the only thing before it are 11,000 other "(null)" entries).

So my guess here is that perhaps we're spinning up but never exiting many nested event loops.  This entrains JS variables that happen to be on the stack, causing us to leak innovateistore.com but also gmail and so on, and it eventually causes us to crash.

The crash report I got from my Dad, which he thinks is probably related but isn't sure, is empty.  I /think/ this lends credence to the theory above.

https://crash-stats.mozilla.com/report/index/dbd699fd-672e-40bf-9543-7d50e2130807

Aside from re-testing with nightly or trying to reproduce this myself, does anyone have ideas as to how to debug this?  Like I say, you are welcome to look at the logs if you've signed an NDA with Mozilla.

Comment 1

[Justin Lebar (not reading bugmail)]

> and it eventually causes us to crash.

...due to exhausting the stack.

Comment 2

[Nicholas Nethercote [inactive]]

MemShrink:P3 due to lack of actionable info at the moment.  We can reassess that if we get more.

Comment 3

[Jens Stutte [:jstutte]]

The reporter stating to not read bugmail makes me believe, this will remain incomplete. But if you still see issues like this, feel free to file a new bug with updated information. Thank you for your support!