Closed
Bug 1096668
Opened 10 years ago
Closed 8 years ago
ptrace lockup related to out of memory
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: from-mozilla, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141013200257 Steps to reproduce: start firefox from an Xterm ulimit -c unlimited ulimit -d 819200 ulimit -m 819200 ulimit -v 1507328 exec firefox -safe-mode restore previously opened tabs (in one case, this includes a number of profiles on facebook) switch between tabs so they get reloaded Actual results: after switching to about the 4th or 5th tab, firefox becomes unresponsive stderr says: Assertion failure: [unhandlable oom] Failed to allocate object while tenuring., at /build/buildd/firefox-33.0+build2/js/src/jscntxt.cpp:1411 If the window becomes unmapped, it is blank (grey) when uncovered. ps -L -Cfirefox shows all the firefox threads in "ptrace" state Expected results: Ideally there would be a way that I can tune firefox to behave nicely with limited memory, but failing that, then just something other than a lock-up; either: (a) gracefully handle the OOM condition - stop processing other tabs and recycle their non-source memory chunks (JIT code, HTML parse trees, etc); (b) kill the current tab; or ultimately (c) terminate firefox, with an explanation (At other times I do see memory-related messages -- to be expected when I'm starving it -- but they don't cause a lockup. The reason I'm starving it is simple: I only have 2.5 GB of real RAM, and my X server crashes if *it* starves.)
Comment 1•10 years ago
|
||
Thanks for the report. You can set the env var XPCOM_DEBUG_BREAK=abort to get crashes instead of the behaviour you see now, see: https://developer.mozilla.org/en/docs/XPCOM_DEBUG_BREAK . I don't think we want to do that for the builds we release to average users. Besides that, I don't know enough about this area of our codebase to be of help, so I'm nudging this vaguely in the right direction in our bug database, and hoping someone else will take it from there.
Product: Firefox → Core
(In reply to :Gijs Kruitbosch from comment #1) Thanks Gijs; I'll try that and report back. (My main issue is that it locks everything up in ptrace when some particular assertions fail; there may that I'll shortly find out about other assertions that I've been happily oblivious to, in which case I'll be back looking for a better solution.)
Comment 3•8 years ago
|
||
@Reporter, Were you able to try the suggestions from Comment 1? Are you still experiencing the issue on latest Firefox versions? - Firefox 43: https://www.mozilla.org/en-US/firefox/new/ - Nightly 46: https://nightly.mozilla.org/
Flags: needinfo?(from-mozilla)
Initially it didn't make much difference, but I've since upgraded (on the Ubuntu-14.04 release path) and eventually lockups seemed to be less of an issue. I'm not sure if the relatively few lockups I've experienced since are related or not.
Flags: needinfo?(from-mozilla)
Comment 5•8 years ago
|
||
Thank you. Then I will mark this as Resolved Worksforme. Please fell free to reopen it if you experience again the issue as described in the bug report.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Comment 6•7 years ago
|
||
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in
before you can comment on or make changes to this bug.
Description
•