Void-packages: Firefox password fields broken by multiprocess setting

Created on 7 Jul 2019  路  25Comments  路  Source: void-linux/void-packages

System

  • xuname:
    Void 5.2.4_1 x86_64-musl GenuineIntel notuptodate hold rrnFFFFFFFFF
  • package:
    firefox-68.0.1_1
    firefox-esr-60.8.0_1

Expected behavior

  1. Selecting password input fields do not crash the tab.
  2. file:// URLs do not crash.

Actual behavior

When browser.tabs.remote.autostart is set to true (the default) :

  1. Selecting password input fields crash the tab.
  2. file:// URLs crash.

Steps to reproduce the behavior

rm -rf /tmp/firefox-void-debug
mkdir /tmp/firefox-void-debug
gdb --args /usr/bin/firefox --profile /tmp/firefox-void-debug --no-remote --new-instance --save-recordings --private-window 'https://bug1451466.bmoattachments.org/attachment.cgi?id=8965047' 2>&1 | tee /tmp/firefox.log
bug

All 25 comments

Setting the multi-process browser.tabs.remote.autostart to false in about:config is a workaround.

The same issue affects file:/// URLs, and can be worked around in the same way.

I can not reproduce the crash with password fields.
Can you provide more information regarding the file URLs? Some logs could be useful.

In case anyone else experiences this issue, feel free to leave a comment.

@jnbr What arch are you on?

Password:

JavaScript warning: resource:///modules/UrlbarView.jsm, line 123: Array.reduce is deprecated; use Array.prototype.reduce instead
console.warn: nsLoginManager: "searchLogins: `formSubmitURL` or `httpRealm` is recommended"
[Parent 11535, Gecko_IOThread] WARNING: pipe error (67): Connection reset by peer: file /builddir/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
[Parent 11535, Gecko_IOThread] WARNING: pipe error (89): Connection reset by peer: file /builddir/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
[Parent 11535, Gecko_IOThread] WARNING: pipe error (82): Connection reset by peer: file /builddir/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358

###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0074,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

file:/// URL:

[Parent 12088, Gecko_IOThread] WARNING: pipe error (67): Connection reset by peer: file /builddir/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
[Parent 12088, Gecko_IOThread] WARNING: pipe error (115): Connection reset by peer: file /builddir/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358

###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0074,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

The mentions of chromium are interesting.

I'm not signed in to Firefox Sync.

Both linux 4.19.59_1 and 4.14.133_1 fail

See also?

Thanks for the logs.

@jnbr What arch are you on?

I use x86_64 and x86_64-musl, but there are more variables. e.g. different gsetting backends.

What else to look for?

I don't have gnome installed so maybe something from that is missing. This is what I do not have installed:
sudo xbps-install -Sn gnome | sort -h | awk '{print $1}' | sed -E 's/-[0-9._]+$//g'

Edit: installing gnome makes no difference.

Unfortunately, the gdb output contains no information about why the tab crashed.

Please provide more information about your system:

  • Which graphic driver do you use?
  • xorg or wayland?

It could be related to running out of shared memory. Please show the output of df /dev/shm

  • mesa-intel-dri-19.1.2_1
  • xorg-server-1.20.5_1
Filesystem     1K-blocks   Used Available Use% Mounted on
tmpfs            4069536 394364   3675172  10% /dev/shm

Shared memory shouldn't be an issue according to these numbers.
The graphics stack is identical to mine, so this doesn't seem to be the case either.

I'm not sure on how to debug this. I will push the update for firefox-68.0.1 later today, I don't expect it to fix your issues but it might be worth a try.

68.0.1 still crashes, log is practically same as before.

console.warn: nsLoginManager: "searchLogins: `formSubmitURL` or `httpRealm` is recommended"
[Parent 2016, Gecko_IOThread] WARNING: pipe error (72): Connection reset by peer: file /builddir/firefox-68.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix
.cc, line 358
[Parent 2016, Gecko_IOThread] WARNING: pipe error (89): Connection reset by peer: file /builddir/firefox-68.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix
.cc, line 358
[Parent 2016, Gecko_IOThread] WARNING: pipe error (82): Connection reset by peer: file /builddir/firefox-68.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix
.cc, line 358

###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0074,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv

###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

firefox-esr-60.8.0_1 has the same problem, with a sligthly more verbose log.

(+ main issue clarified)

Other things that give the same crash are losing the connection or attempting to load domains that don't exist.

Edit: also I noticed local files work well, it's only directories that fail.
```text
echo hi > /tmp/test.html
firefox /tmp/test.html # works
firefox /tmp/ # crashes

Just a note, this is a Musl issue. It's happening on Alpine Linux and Gentoo Musl too.

IMDB loads with some visuals for a while but eventually crashes, which seems to break the pattern of http{s,} pages working fine.

Just a note, this is a Musl issue. It's happening on Alpine Linux and Gentoo Musl too.

I am unable to duplicate this issue on arm64 or amd64 musl gentoo. Are you sure your using the upstream patches in void for musl support in mesa?

@anarchpenguin well, I'm not using Void, but Alpine Linux which uses Musl too. Like I said, it's happening on more distros, including Gentoo Musl. However, for some reason it can't be reproduced by everyone, which makes the whole thing way more annoying to debug.

72.0.2_1 still crashes on local directories, but password fields work now!

I am using Alpine, but uninstalling dconf fixed it for me.

Also, I think the password related crash is related to this.

Uninstalling dconf worked for me as well! I haven't had the password crash for a while though

Nice that you found a solution. I'm closing this, feel free to reopen or open a new issue if the problems appear again.

It's nice but more of a hack than a solution. Lots of other stuff unfortunately require dconf...

For me it was fixed since version 72.0, and that is with dconf installed. This is on Alpine Linux. Are you guys absolutely sure dconf was causing the problem? It seems unlikely to me.

@PureTryOut Are you talking about password fields, or local directories, or both? E.g. for me file:///tmp/index.html works but file:///tmp/ crashes. https://github.com/void-linux/void-packages/issues/12885#issuecomment-578443007 :wink:

Just password fields. Local directories indeed still crashes, but luckily I don't need that feature anyway.

Perhaps better to split that off into a separate issue now that it's clear they are caused by different things?

Was this page helpful?
0 / 5 - 0 ratings