ptrace lockup related to out of memory

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
4 years ago
10 months ago

People

(Reporter: from-mozilla, Unassigned)

Tracking

33 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.)
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.
Component: Untriaged → Untriaged
Product: Firefox → Core
(Reporter)

Comment 2

4 years ago
(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

3 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)
(Reporter)

Comment 4

3 years ago
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

3 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
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
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.