613584 - Minefield crashes with jemalloc, leaks mem indefinitely under Windows malloc

Status: RESOLVED WORKSFORME

(Core :: Memory Allocator, defect)

Description

[Olipro]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101119 Firefox/4.0b8pre
Build Identifier: parent: 57921:0830d8f97936 tip (from hg summary)

I have 2 windows open with about 17 tabs open per window, and it's consuming 1GB of RAM (private working set)

Eventually and inevitably, although I have no idea why, Minefield *WILL* crash, it always crashes as a result of me opening a new website or occasionally from simply clicking a link... ironically the minidump I've included was a result of me clicking the Submit a bug link on the main page of this website.

There is no real pattern to the crashes as far as I can see, I suspect that it's quite probably memory management issues, possibly related to the javascript engine/JIT.

The minidump is provided in the format that WinDbg will parse, I hope it's illusive.

Reproducible: Sometimes

Steps to Reproduce:
1. Have around 35 tabs open
2. use Minefield till it crashes
3. Profit.

Comment 1

[Olipro]

Attachment: Firefox crash mindump (WinDbg compatible)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm.  Did you not get a crash reporter dialog?

And are you using a 64-bit Windows build?  It sure looks like you are....

Comment 3

[Olipro]

yes, I roll the builds myself, hence no crash reporter thingy.

I've also added a second minidump; this one occured as a page was loading, looking at the call stack seems to me like it was processing some javascript.

Comment 4

[Olipro]

Attachment: Firefox crash mindump (WinDbg compatible)

Comment 5

[Boris Zbarsky [:bzbarsky]]

I don't have WinDbg to hand right now.... what do the stacks look like?

Comment 6

[Olipro]

taken from the first minidump:

mozcrt19!malloc_rtree_set+0xe7
mozcrt19!chunk_alloc+0x67
mozcrt19!huge_malloc+0x9f
mozcrt19!huge_ralloc+0x1c9
mozcrt19!realloc+0x44
mozjs!JSRuntime::realloc+0x4c
mozjs!js::Vector<unsigned short,32,js::ContextAllocPolicy>::growStorageBy+0x7c
mozjs!write_string+0x372
...(bunch of calls to JA, JO and Str)
mozjs!js_Stringify+0x6c1
mozjs!js_json_stringify+0xfe
mozjs!js::Interpret+0x5a50

I can take it deeper if you want.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Nah.  Sure looks like some sort of OOM thing... but not going through mozalloc or anything....

What line does +0xe7 correspond to?

Comment 8

[Olipro]

line 2408 of memory\jemalloc\crtsrc\jemalloc.c

malloc_spin_unlock(&rtree->lock);

Comment 9

[Boris Zbarsky [:bzbarsky]]

Huh.  That's ... really weird.

Comment 10

[Olipro]

indeed, I don't get this with the 32 bit builds... pointer truncation perhaps?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Doesn't seem that likely....

Just to check, MOZ_MEMORY_WINDOWS and MOZ_MEMORY are both defined in your build, right?

Comment 12

[Olipro]

yep

Comment 13

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Olipro, can you try building with --disable-jemalloc and seeing if the crashes, to narrow things down a bit?

Comment 14

[Olipro]

ok, I've built with jemalloc disabled and now it doesn't crash any more.

I did have a memory leak going on with Adblock plus which has since markedly improved after updating the extension; I suspect that under jemalloc, it'll crash but under the standard windows allocator, it won't.

Comment 15

[Olipro]

OK, so here's what I've ascertained: with jemalloc, Firefox will eventually crash.

Without jemalloc, it will simply leak memory continuously; just build it and use it for about 24 hours and watch it grow... obviously 32bit builds will top out at 4GB usage (under WOW64).

Comment 16

[Scoobidiver (away)]

Olipro, does it still happen? If so, can you provide a refreshed stack trace?

Comment 17

[Olipro]

This bug dates from the days when Firefox 4 was in development - I still roll my own builds of Firefox as Win64 and they generally work fine.

Given both that and the age of this bug, I doubt the problem is still relevant.