User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20061201 Firefox/188.8.131.52 (Ubuntu-feisty) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061201 Firefox/220.127.116.11 (Ubuntu-feisty) firefox aborts after opening the URL Reproducible: Always Steps to Reproduce: 1. start ff 2. open URL http://udaff.com/ 3. ff (18.104.22.168) aborts Actual Results: ff (22.214.171.124) aborts Expected Results: I wish to see web page content.
See nothing special happen here when I load the site with 126.96.36.199 on Windows XP.
Vladimir, does this happen using Firefox 188.8.131.52 with a new profile? Be sure to use an official mozilla.com build. http://kb.mozillazine.org/Profile_Manager
Whiteboard: CLOSEME - 06/15
(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
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.)
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.