1565185 - Sometimes, new tabs gets unresponsive

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P2)

Description

[Hugo Fernandez]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

When I open a new tab, or open a link in new tab, or a new search in the search field, sometimes the tab gets unresponsive.

Actual results:

The tab opens empty, and loading. It never finish. It is impossible to reload, go to google, open preferences,etc. Tab is useless. The only thing works is closing the tab and open another one. When a tab hangs, an orphan IPC Launch # process is opened, consuming memory. Sometimes, when some of this type of processes are generated, all PC memory is consumed, and PC hangs.

In Ubuntu Mate 16.04 64 bits. We are updating firefox to latest version. 300 PCs updated from a total amount of 750 Pcs

Expected results:

Always open working tabs

Comment 1

[Pablo]

Hi,
I was unable to replicate the issue using Untu 18.04 64bit.

Please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.

If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Lastly test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Regards
Pablo

Comment 2

[Hugo Fernandez]

I've Tested on Ubuntu Mate 18.04 64 bits updated, and Firefox 68, with same result. With a new profile, nothing changes.
I Will try un safe Mode.

Comment 3

[Hugo Fernandez]

Console error when this bug happens:

Before tab hangs some errors from other tabs:
###!!! [Child][MessageChannel] Error: (msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Closed channel: cannot send/recv
###!!! [Child][MessageChannel] Error: (msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Closed channel: cannot send/recv
###!!! [Child][MessageChannel] Error: (msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Closed channel: cannot send/recv
###!!! [Child][MessageChannel] Error: (msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Closed channel: cannot send/recv
###!!! [Child][MessageChannel] Error: (msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Closed channel: cannot send/recv

When one tab hanged:
[Parent 5484, Gecko_IOThread] WARNING: pipe error (107): Conexión reinicializada por la máquina remota: file /build/firefox-tGfEvD/firefox-68.0.1+build1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

###!!! [Child][MessageChannel] Error: (msgtype=0x530005,name=PHttpChannel::Msg_Cancel) Closed channel: cannot send/recv

Comment 4

[Hugo Fernandez]

(In reply to Pablo from comment #1)

Hi,
I was unable to replicate the issue using Untu 18.04 64bit.

Please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.

If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Lastly test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Regards
Pablo

Hi Pablo, on comment #3 I think I found the error. Same issue in two different computers, at work and at home. Ubuntu Mate 16.04 Firefox 67 and Ubuntu Mate 18.04 Firefox 68.

Comment 5

[Pablo]

added component tabbed browser

Comment 6

[adam.bambuch2]

Attachment: backtrace.txt

I have the same problem. I tried to run firefox in gdb and found that after some time a thread gets SIGPIPE.
Backtrace in attachment.

Comment 7

[Hugo Fernandez]

Tested in firefox 69.0.1 downloaded from firefox website, disabled addons, new profile, and running on --safe-mode: same problem

Comment 8

[Hugo Fernandez]

(In reply to Hugo Fernandez from comment #7)

Tested in firefox 69.0.1 downloaded from firefox website, disabled addons, new profile, and running on --safe-mode: same problem
And also firefox 69.0.2

Comment 9

[adam.bambuch2]

I found that it didn't happen when user namespace sandboxing is disabled, so "MOZ_ASSUME_USER_NS=0 firefox" can be used as a workaround.

Comment 10

[Ellis]

I am having the same issue. I have tried setting via about:config the following

Changed

security.sandbox.content.level from 4

to

security.sandbox.content.level to 0

It seems to be behaving now that I made this change.

Comment 11

[Ellis]

(In reply to Ellis from comment #10)

I am having the same issue. I have tried setting via about:config the following

Changed

security.sandbox.content.level from 4

to

security.sandbox.content.level to 0

It seems to be behaving now that I made this change.

BTW, I am running Linux Mint 19 and Firefox version 69.0.1

Comment 12

[Ellis]

Subsequently set security.sandbox.content.level to 3 so have some sandboxing, all ok at level 3 also.

Seems level 4 introduces issues.

Comment 13

[Hugo Fernandez]

Hi,

Maybe I found another workaround. Setting "Content process limit" from 8 (default) to 2 did the trick. I tested in four PCs.
https://support.mozilla.org/en-US/kb/performance-settings

I don't know if this setting is related to security.sandbox.content.level. I assume changing "content process limit" is worse in terms of performance, but changing sandbox level is worse in terms of security, isn't it?

Comment 14

[Hugo Fernandez]

(In reply to Hugo Fernandez from comment #13)

Hi,

Maybe I found another workaround. Setting "Content process limit" from 8 (default) to 2 did the trick. I tested in four PCs.
https://support.mozilla.org/en-US/kb/performance-settings

I don't know if this setting is related to security.sandbox.content.level. I assume changing "content process limit" is worse in terms of performance, but changing sandbox level is worse in terms of security, isn't it?

I applied this config at 700 pcs two weeks ago and the issue was solved.

Comment 15

[kdanilaitisss]

firefox 71.0 on ubuntu 18.04 same problem

Comment 16

[Hugo Fernandez]

With firefox 72.0 same problem again

Comment 17

[Chris Peterson [:cpeterson]]

Nika thinks this is probably a Core::IPC bug, not a DOM: Content Processes.

Comment 18

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

(In reply to Hugo Fernandez from comment #0)

When a tab hangs, an orphan IPC Launch # process is opened, consuming memory.

(In reply to adam.bambuch2 from comment #9)

I found that it didn't happen when user namespace sandboxing is disabled, so "MOZ_ASSUME_USER_NS=0 firefox" can be used as a workaround.

This probably isn't IPC: it looks like the same issue as bug 1604218 and bug 1614886.

The other cases of this that we've seen have involved ESET antivirus preloading a .so that changes the behavior of system library calls like open.

Comment 19

[Ellis]

I recently had a Eset Nod32 Antivirus Update that addressed issues with Chrome and Firefox.

So I decided to change my security.sandbox.content.level from 3 back to 4 (the default), and all seems fine now.

I dont know if the update to Eset made the difference for if the later version of Firefox V74 fixed it, but there you have it, all seems ok now.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

https://forum.eset.com/topic/21896-chrome-79-always-starts-a-core-dump-and-crashes/page/5/?tab=comments#comment-111090

Version 4.0.95.0
Fixed: Compatibility of Real-time scanner with 3rd party applications, like Google Chrome or Firefox

That's a good outcome then, because earlier they were saying everyone was imagining this: https://forum.eset.com/topic/21896-chrome-79-always-starts-a-core-dump-and-crashes/?do=findComment&comment=105983

Comment 21

[Gian-Carlo Pascutto [:gcp]]

ESET now has a fix out, I'm going to close this so we can differentiate new problems with similar symptoms.