1368692 - (Linux) Web/local content processes get stuck and are not cleared after crash:restart

Status: RESOLVED DUPLICATE of bug 1363378

(Core :: DOM: Content Processes, defect)

Description

[Adrian Florinescu [:aflorinescu]]

[Enviroment:]
-Ubuntu 16.04 x 64          / Not reproducible on OSX or Windows
-Nightly 55.0a1 Build ID 20170530100155

[Steps:]
1. Launch FF.
2. Install the crash me now add-on - https://addons.mozilla.org/en-US/firefox/addon/crash-me-now-simple/?src=ss
3. Open about:config and check values for dom.ipc.processCount (4) and dom.ipc.processCount.file (1) - defaults currently on Nightly.
4. Open System Monitor and track the PIDs for the pages you are going to open.
5. Open in new tabs 6 web pages and 2-3 local files.
6. Crash and restart Firefox using the Crash me addon installed at step 2 - do this while following the activity monitor for the Firefox processes.
7. If the session is not automatically restored, restore it.


[Expected Result:]
3. dom.ipc.processCount = 4 -> 4 PIDs are going to be allocated to the 6 web pages
   dom.ipc.processCount.file  = 1 -> 1 PID is going to be allocated for the 3 local files opened.
4. 5 total PIDs + 1 firefox-bin
6. The FF processes are closed.
7. If the first tab restored is a web, then 2 PID active (1 process for the web page, 1 the prelaunch)

[Actual Result]
3. dom.ipc.processCount = 4 -> 6 web pages are going to be allocated to the 4 PIDs 
   dom.ipc.processCount.file  = 1 -> 1 PID is going to be allocated for the 3 local files opened.
4. 5 total PIDs + 1 firefox-bin
6. The FF processes remain open. (right click properties will state: sleeping)
7. The restore will open new PIDs as it should, but the old ones (before the crash are still opened)


[Note:]
Redoing the above steps using a normal restart instead of crash.me will not replicate this issue.

Comment 1

[Adrian Florinescu [:aflorinescu]]

Additional note to the above bug:

Seems to me that this is reproducible with the pref browser.tabs.remote.separateFileUriProcess set on false as well. With the pref set on false the WebContent process is not closed/restarted(the PID remains the same) when using crash.me, also I get the following in the terminal, after FF is closed - and no process is visible in system monitor:
Sandbox: Unexpected EOF, op 0 flags 01101 path /tmp/GeckoChildCrash5883.extra

Comment 2

[Simona Badau, Desktop QA]

This issue affects also Nightly 56.0a1 (Build ID: 20170622100312).
I could not reproduce this issue on the latest beta (Firefox 55 beta 3) or release (Firefox 54).
The issue reproduces on Nightly 54 and Nightly 55.

Comment 3

[Jim Mathies [:jimm]]

See comment 1, looking for help triaging this.

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Could this be a duplicate of bug 1363378?

Comment 5

[Bob Owen (:bobowen)]

The start of comment 1 seems to suggest that this happens regardless of browser.tabs.remote.separateFileUriProcess.
So I guess jld is right.

Adrian - can you still reproduce this.

Comment 6

[Adrian Florinescu [:aflorinescu]]

Hey Bob, 
Sure, I could verify this bug, but do you know perchance of a nice way to crash the browser? "Crash me now" is a legacy add-on now, hence not usable on 58 anymore.

Comment 7

[Bob Owen (:bobowen)]

(In reply to Adrian Florinescu [:AdrianSV] from comment #6)
> Hey Bob, 
> Sure, I could verify this bug, but do you know perchance of a nice way to
> crash the browser? "Crash me now" is a legacy add-on now, hence not usable
> on 58 anymore.

In Nightly, I think you should be able to flip the pref extensions.legacy.enabled.

Comment 8

[Adrian Florinescu [:aflorinescu]]

Thanks Bob. I managed to get crash me working for 58 but for 57 I used as alternative snippet to crash FF:

"Cu.import("resource://gre/modules/ctypes.jsm");
let zero = new ctypes.intptr_t(8);
let badptr = ctypes.cast(zero, ctypes.PointerType(ctypes.int32_t));
badptr.contents;
"

While crashed, I can only see the ping sender and crash reporter in the process list, but they are new PIDS and they are closed after the crash submit is performed. Submitting and restoring session of the browser doesn't reproduce the comment 0 bug.

One thing I've noticed is that when opening FF from console, after the submit crash is pressed, the FF crash window persists a few seconds and afterwards the terminal is not fully disengaged - when choosing close instead of restart (line 4) , which makes me think that might still be something hanged there.
~$ ./Documents/ff/1Nightly/x64/latest/firefox/firefox-bin -p -no-remote
1. ExceptionHandler::GenerateDump cloned child 16002
2. ExceptionHandler::SendContinueSignalToChild sent continue signal to child
3. ExceptionHandler::WaitForContinueSignal waiting for continue signal...
4. adrian.florinescu@P5099:~$ Failed to open curl lib from binary, use libcurl.so instead