crash [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0xe08a5 ] when loading during a while a long page

RESOLVED WORKSFORME

Status

()

Core
Layout
--
critical
RESOLVED WORKSFORME
7 years ago
7 years ago

People

(Reporter: Jarod_, Unassigned)

Tracking

({crash})

2.0 Branch
x86_64
Windows 7
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

The problem appears on my intranet. I've been able to reproduce the bug in creating a similar page and the way it loads (see the url attached).

When loading a long page which it's long to load (because of the server side code that writes row by row the TABLE), then I have Firefox that increases its memory size (from 400Mo to 1.2Go) and that finally crashes without loading the full page.

I'll be happy to provide more information.

I tried to start Firefox 4 without components (in safe mode), but the problem is still there.
I tried the same page with Firefox 3.6 (Windows 7 32bits) and it works perfectly.

Reproducible: Always

Steps to Reproduce:
1. Go to a long page that is long to load

Actual Results:  
Crash of Firefox

Expected Results:  
Load the full page, and release the memory

My computer uses 4Go of RAM, under Windows 7 64bits
The page works with IE.
I use the last stable version of Firefox 4 downloaded from Mozilla
(Reporter)

Updated

7 years ago
Version: unspecified → 4.0 Branch

Comment 1

7 years ago
Please post the crash ID from about:crashes
https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
(Reporter)

Comment 3

7 years ago
My server doesn't like that people tests the test page :-) So I'm going to remove it. If you want to test my crash.php, please let me know by email and I'll re-active it for your test (or I can send you the page directly).

Thanks.
(In reply to comment #2)
That report isn't available. Can you get another?
Keywords: stackwanted
(Reporter)

Comment 5

7 years ago
(In reply to comment #4)
> (In reply to comment #2)
> That report isn't available. Can you get another?

Two other crash ID : bp-62a45010-0861-4653-aead-911b42110330 and bp-a391bcbb-b939-47c3-a74b-7f3422110330

Also you can download the crash.php file from http://dl.free.fr/n2vJVa7o3 if you want to test on your own server or locally.

Thanks.
This is a OOM (Out of Memory) Crash.
I fail to reproduce against Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756 and Mozilla/5.0 (Windows NT 5.1; rv:2.2a1pre) Gecko/20110401 Firefox/4.2a1pre ID:20110401030438 using the Example from Comment 5.

Does setting "gfx.direct2d.disabled" to "true" via "about:config" and restarting Firefox show a Difference in the Behavior of Loading that Example?
Keywords: stackwanted → crash
Summary: crash when loading during a while a long page → crash [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0xe08a5 ] when loading during a while a long page
(Reporter)

Comment 7

7 years ago
I tried to change "gfx.direct2d.disabled" to "true", then I've restarted Firefox, but no chance...

The crash ID : bp-5f753430-89b1-4aa7-9e3a-f8ea12110402

Also if you don't reproduce the issue it's certainly because your system has enough memory, but what about the Firefox memory size ? Does it increase and increase and increase ? Is that a normal behavior ? More than 1Go for a process sounds too much big for me...

Thanks for trying to help !
(Reporter)

Comment 9

7 years ago
Created attachment 523855 [details]
Stacktrace with WinDbg
(Reporter)

Comment 10

7 years ago
@XtC4UaLL, any update about that? Thanks.
Ah no, got out of my Sight.
Moving this to Layout by looking at the Stacktrace and Comment 0.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 4.0 Branch → 2.0 Branch
All the stack says is we ran out of memory while trying to paint the page. We know we're running out of memory: comment 0 says so.

The question is why we're running out of memory when 3.6 does not.

Jarod_, how much RAM does 3.6 use to render the page in question?
(Reporter)

Comment 13

7 years ago
(In reply to comment #12)
> All the stack says is we ran out of memory while trying to paint the page. We
> know we're running out of memory: comment 0 says so.
> 
> The question is why we're running out of memory when 3.6 does not.
> 
> Jarod_, how much RAM does 3.6 use to render the page in question?

The 3.6 runs with 4Go of RAM.
I've also tried to run a portable version of Firefox 3.6 on my computer (which runs Firefox 4). And it works ok.

With 3.6 I can see that the RAM used by Firefox is growing but goes down to keep a stable amount of RAM.
With FF4 I can see that the RAM used by Firefox is growing and growing, and never goes down...
(Reporter)

Comment 14

7 years ago
FYI the problem is still there with Firefox 4.0.1

Thanks.
(Assignee)

Updated

7 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0xe08a5 ]
(Reporter)

Comment 15

7 years ago
The bug seems to be fixed with Firefox 5.0
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.