622291 - Crash when loading websites

Status: RESOLVED DUPLICATE of bug 624645

(Core Graveyard :: Nanojit, defect)

Description

[Andreas Jung]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre

The latest nightly builds have been very unstable on my computer and crash regularly. They seem to crash in a way though, that either the crash reporter never opens or the submitted reports are invalid (they are at least inaccessible, I suspect they are corrupted).

The crash reports are:
http://crash-stats.mozilla.com/report/index/bp-d6c72888-5053-414f-9339-4192f2101231
http://crash-stats.mozilla.com/report/index/bp-b9e571a9-741b-4dbb-8cd3-f8a082101231

A crash report that was submitted after attaching, analyzing and detaching WinDbg (that actually shows up):
http://crash-stats.mozilla.com/report/index/bp-2c022370-1b87-462f-9343-2d4872101231

Reproducible: Always




Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre
http://hg.mozilla.org/mozilla-central/rev/b083bc8b79ab

Comment 1

[Andreas Jung]

Attachment: Complete WinDbg log

Since all crash reports showed up as unavailable I used WinDbg to get crash analysis.

Comment 2

[timeless]

err, you crashed here:

0013b764 7815c4eb kernel32!RaiseException+0x53
0013b79c 78164ed3 MOZCRT19!_CxxThrowException(void * pExceptionObject = 0x0013b7ac, struct _s__ThrowInfo * pThrowInfo = 0x781caa14)+0x46 [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161]
0013b7b4 004f2700 MOZCRT19!operator new(unsigned int size = 0)+0x73 [e:\builds\moz2_slave\cen-w32-ntly\build\obj-firefox\memory\jemalloc\crtsrc\new.cpp @ 61]
0013b7c8 004661ae mozjs!js::InitJIT(struct js::TraceMonitor * tm = 0x00000000)+0x140 [e:\builds\moz2_slave\cen-w32-ntly\build\js\src\jstracer.cpp @ 7610]
0013b7d8 00461b90 mozjs!JSCompartment::init(void)+0xbe [e:\builds\moz2_slave\cen-w32-ntly\build\js\src\jscompartment.cpp @ 104]
0013b7f4 0042840f mozjs!js::gc::NewCompartment(struct JSContext * cx = 0x05a583a0, struct JSPrincipals * principals = 0x0013b714)+0x40 [e:\builds\moz2_slave\cen-w32-ntly\build\js\src\jsgc.cpp @ 2586]
0013b800 1023b6d4 mozjs!JS_NewCompartmentAndGlobalObject(struct JSContext * cx = 0x10163c88, struct JSClass * clasp = 0x10c96c50, struct JSPrincipals * principals = 0x713ce770)+0xf [e:\builds\moz2_slave\cen-w32-ntly\build\js\src\jsapi.cpp @ 2977]

Comment 3

[Andreas Jung]

Sorry, I had copied the signature from bp-2c022370-1b87-462f-9343-2d4872101231, but this is incorrect.

Comment 4

[Andreas Jung]

The crash always occurs when Firefox is running out of memory.
I'm on Windows XP SP3 32-bit, so the memory limit is at 2GB and when Firefox crashes it always is only a few KB away from that limit.

Comment 5

[Wayne Mery (:wsmwk)]

how many tabs?
any particular websites with many multiple tabs?

Comment 6

[Andreas Jung]

I have 10-15 tabs always opened (these take about 800MB - 1GB at the moment; I don't have exact numbers, but this seems a lot more than a few weeks ago).

How much additional tabs it takes until Firefox crashes depends on the pages I open additionally to these always opened tabs.

At the moment I have 30 additional tabs opened (i.e. overall 45 tabs opened) and Firefox still runs stable (at 1500 MB memory usage).

But if I open certain websites the crash happens after only opening a few additional tabs (~5-10).

I didn't track down all the sites that create an extremely high memory usage, but I most often get the crashes browsing pixiv.net or http://www.bittersweetcandybowl.com/candybooru/

I will try to get numbers on how much memory the same set of tabs uses in Minefield (standard profile + new profile) and the latest Firefox stable release.

Comment 7

[Nicholas Nethercote [inactive]]

Bug 623428 might help with this?

Comment 8

[Nicholas Nethercote [inactive]]

(In reply to comment #7)
> Bug 623428 might help with this?

Yeah, I'm pretty sure it will.  There were some allocations in js::InitJIT() that weren't being checked for failure, and the patch for bug 623428 will fix it.

Comment 9

[Nicholas Nethercote [inactive]]

I'm marking this as a duplicate of bug 624645.  That bug was filed after this one, so strictly speaking it's the duplicate, but the comments in this bug are a bit cluttered so I'll mark this as the duplicate.