firefox aborts after opening the URL

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
12 years ago
9 years ago

People

(Reporter: vladimir.alter, Unassigned)

Tracking

2.0 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)

firefox aborts after opening the URL

Reproducible: Always

Steps to Reproduce:
1. start ff
2. open URL http://udaff.com/
3. ff (2.0.0.3) aborts
Actual Results:  
ff (2.0.0.3) aborts

Expected Results:  
I wish to see web page content.
(Reporter)

Updated

12 years ago
Version: unspecified → 2.0 Branch
See nothing special happen here when I load the site with 2.0.0.3 on Windows XP.
Vladimir, does this happen using Firefox 2.0.0.4 with a new profile? Be sure to use an official mozilla.com build.

http://kb.mozillazine.org/Profile_Manager
Whiteboard: CLOSEME - 06/15
(Reporter)

Comment 3

12 years ago
(In reply to comment #2)

Samuel, seems now I know exactly why no one (except me) can reproduce the error.
From time to time I change sysctl variable vm.overcommit_memory on my system (due to 3rd party software needs).
I don't see the error when the variable have (default in ubuntu) value 0.
When value is 2 ff segaults in that site and many other (so I don't think this is site-related problem) sites.

Maybe ff doesn't check if NULL == malloc() when allocates memory or something?
It's just a guess.

To reproduce one have to set vm.overcommit_memory to value 2 (and reboot?);
I assume this segfault will be reproduced when virtual ram almost full.

P.S. gnome-browser acting (segfault) the same as ff, so probably error not in browsers, but in gecko or some other part of shared code/engine.
Vladimir, do you have this same problem using a recent trunk build?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Whiteboard: CLOSEME - 06/15

Comment 5

11 years ago
vladimir: we do have some oom handling, but our handling isn't perfect. [in fact, it has two huge gaping holes, 1. failed c++ allocations will abort(). 2. failed allocations in most "gnome system" libraries will abort().]

If you're interested in helping us, you'd need to build your own binary (trunk please, not branch), w/ --enable-debugger-info-modules, and make sure ulimit -c is unlimited. (Trying to run a crash reporter when you're out of memory is a losing proposition, however if you're feeling adventurous, you're welcome to try a minefield nightly w/ instead - I am interested in finding out if it works.)

Comment 6

9 years ago
This bug was reported using a version of Firefox that security and stability updates are no longer provided for.  All users are strongly encouraged to upgrade to Firefox 3 by selecting 'Check for Updates' in the Help menu or by going to http://www.mozilla.com/en-US/firefox/firefox.html

If you can no longer reproduce this bug using the latest Firefox 3.0.x version, please change the status of this bug to 'RESOLVED' 'WORKSFORME'.

If you can still reproduce this bug, please provide additional details to help resolve this issue.
Resolving as WORKSFORME.  If the issue appears in Firefox 3.5, we will reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.