View previous topic :: View next topic |
Author |
Message |
dbtx Tux's lil' helper
Joined: 20 Jan 2020 Posts: 117
|
Posted: Tue Nov 16, 2021 8:02 pm Post subject: emerged world overnight -> every firefox tab crashes |
|
|
Hi again. This is from yesterday and I wrote a much longer post but decided to keep looking first. I figured out the one profile that was still working was the one where multi process browsing / e10s / whatever had not been switched on in prefs.js. Searching for Code: | [Parent][RunMessage] Error: Channel error: cannot send/recv | turned up this support question and the chosen solution worked for me though it's not optimal. These go into prefs.js or about:config... Code: | browser.tabs.remote.autostart = false
browser.tabs.remote.autostart.2 = false | Here's the list of updates that had come in right when it broke, grepped out of /var/log/emerge.log in case there's any smoking gun I can't see. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Wed Nov 17, 2021 2:47 am Post subject: |
|
|
What do you mean "every firefox tab crashes"? What version of Firefox are you using? Is Firefox displaying some internal message stating that the tab failed? Do you get a kernel message confirming that a process terminated? If I had to guess based on the limited information available, I would guess that this is another case of a system call sandbox that was set very strictly, that then falsely panics when a new glibc changes the details of how a C library call is implemented. Your workaround is probably only functional because disabling multi-process mode inhibits the use of the sandbox. |
|
Back to top |
|
|
Banana Veteran
Joined: 21 May 2004 Posts: 1357 Location: Germany
|
|
Back to top |
|
|
dbtx Tux's lil' helper
Joined: 20 Jan 2020 Posts: 117
|
Posted: Wed Nov 17, 2021 7:56 pm Post subject: |
|
|
I wanted to put that up before I left for work in case anyone else went looking for a similar thing. This is mostly what I was writing on Monday morning:
I had been running an instance of Waterfox Classic 2021.04.2 for some days, mostly because 2021.10 doesn't successfully compile (yet, and it probably won't, because rustc consistently chokes on a couple things that I know nothing about including one officially unmaintained library, of course, but anyway). Last night I closed a third window with around 20 tabs.
On my way to sleep I started another deep update; it was done when I got up. I also ran a --depclean later in the morning.
I can't find any log for what exactly I removed, if it exists. I only remember spidermonkey specifically and a few other things that "should" have been disposable.
After some hours of still using Waterfox with that days- or weeks-old process tree, I went to reopen that closed window, and the first tab to show and try to reload immediately crashed. It doesn't show up any segfault; it just shows "Gah. Your tab just crashed" and Restart/Close buttons.
Tabs in the current window(s) would still work, as long as I had viewed that one at least once since restarting, otherwise it would still have to do its initial reload, so it would crash.
(at least, I think I remember trying that-- sorry, I'm trying to be a good detective but I didn't realize then how screwed up ${something} is)
After I decided there was nothing I needed to finish up, I restarted it, and that didn't help. I started trying to run with other profiles and one of them, which I haven't seriously used in a fairly long time, actually works.
The profiles that I haven't used for far longer, and which I should have deleted years ago because they were only used for pretending to work on and test an extension, which have almost nothing interesting done in them or to them, also crash.
I made a brand new profile and its first tab ever also crashed. I tried --safe-mode but it didn't help.
Waterfox is built locally for the sake of good CFLAGS/CXXFLAGS, so portage wouldn't have known if I still needed something that happened to be pulled in by an old Firefox install, so I started thinking I might have depcleaned it.
But then I tried firefox-bin-88.0.1 and the same thing happens. If I run it from a terminal, I get this output in which the first tab to try to load crashed, so I clicked on Restore This Tab (5x) and the tab always just crashes immediately. I think maybe "Gah your tab just crashed" could be just the one-size-fits-all assumption when communication has broken down. FWIW, there's nothing about a segfault in dmesg-- just a lot of those lines and the shorter "[Parent][RunMessage] Error: Channel error: cannot send/recv" in .xsession-errors. I won't go to a newer FF because I get the feeling Mozilla is literally trolling everyone with their "design decisions," and the only reason I had 88 around is for those broken-by-design sites where WebComponents is absolutely required, which waterfox-classic (and palemoon) will presumably never have.
I tried rebooting, revdep-rebuild, and downgrading dbus to what I think was the patchlevel I had, on a hunch. I tried downgrading glibc but not to the second most recent version-- the only lower thing available was stable 2.33 and when I tried to merge it, portage said 'nope!' so I left it alone.
and emerge --info firefox-bin The odd CFLAGS are so I can share the root fs with an old laptop. I rsync'ed them somewhat recently so it's also a halfway decent backup, but I'd like to not update everything again if I don't have to. If I emerge world and FF just goes sideways again, it doesn't really solve anything. At least I have another working machine with a slightly less fresh home directory already in it.
Hu's suggestion about the sandbox makes the most sense, for now. I still need to try waterfox-classic-bin from upstream. I generally avoid it because it's noticeably slower-- probably due to lowest-common-denominator CFLAGS. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Wed Nov 17, 2021 8:41 pm Post subject: |
|
|
If I am right, then your options are:- Permanently disable the Firefox security sandbox. This is probably not a good idea, but could be interesting for testing.
- Update to a version of Firefox that loads a security sandbox that is compatible with glibc.
- Run a fully statically linked Firefox so that it does not use glibc at all. Such a firefox would need to have been statically linked with a glibc compatible with Firefox's system call sandbox.
Downgrading glibc, in addition to being difficult and risky, would only be a diagnostic, not a fix. I doubt waterfox-classic-bin will work for you, unless it satisfies point 1 or point 2 above.
You might get more information via an strace of the broken browser, but beware that it will be extremely verbose, and if I'm wrong, the strace will show nothing of interest.
You say there are no segmentation fault notes in dmesg. Does the kernel log anything at all around the time this happens? It looks like a seccomp violation ought to trigger an audit message, if those have not been explicitly suppressed. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|