Firefox crashing like there is no tomorrow

English Applications
41

TL;DR: main process is crashing. Something user interface-ish, possibly GLib related. Remember that this is still user-specific, so must be something in the environment.

(gdb) bt full
#0  0x00007ffff791fdef in poll () at /lib64/libc.so.6
#1  0x00007fffea7961c2 in PollWrapper(_GPollFD*, unsigned int, int) () at /usr/lib64/firefox-esr/libxul.so
#2  0x00007ffff581bb51 in ??? () at /usr/lib64/libglib-2.0.so.0
#3  0x00007ffff581c1bc in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#4  0x00007fffea795def in nsAppShell::ProcessNextNativeEvent(bool) () at /usr/lib64/firefox-esr/libxul.so
#5  0x00007fffea6e41c4 in nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) () at /usr/lib64/firefox-esr/libxul.so
#6  0x00007fffe6d56729 in nsThread::ProcessNextEvent(bool, bool*) () at /usr/lib64/firefox-esr/libxul.so
#7  0x00007fffe6d4a36b in NS_ProcessNextEvent(nsIThread*, bool) () at /usr/lib64/firefox-esr/libxul.so
#8  0x00007fffe74fc0f0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () at /usr/lib64/firefox-esr/libxul.so
#9  0x00007fffe74a8eae in MessageLoop::Run() () at /usr/lib64/firefox-esr/libxul.so
#10 0x00007fffea6d7388 in nsBaseAppShell::Run() () at /usr/lib64/firefox-esr/libxul.so
#11 0x00007fffea7c143c in nsAppShell::Run() () at /usr/lib64/firefox-esr/libxul.so
#12 0x00007fffeb21d5ee in nsAppStartup::Run() () at /usr/lib64/firefox-esr/libxul.so
#13 0x00007fffeb31b185 in XREMain::XRE_mainRun() () at /usr/lib64/firefox-esr/libxul.so
#14 0x00007fffeb31bcaf in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/lib64/firefox-esr/libxul.so
#15 0x00007fffeb31c400 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/lib64/firefox-esr/libxul.so
#16 0x000055555556446d in do_main(int, char**, char**) ()
#17 0x0000555555563732 in main ()

(gdb) info threads
  Id   Target Id                                           Frame 
* 1    Thread 0x7ffff7e7c780 (LWP 24218) "firefox-esr"     0x00007ffff791fdef in poll () from /lib64/libc.so.6
  3    Thread 0x7ffff73ff6c0 (LWP 24223) "AsyncSi~lThread" 0x00007ffff792043c in read () from /lib64/libc.so.6
  4    Thread 0x7fffe47ff6c0 (LWP 24225) "pool-spawner"    0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  5    Thread 0x7fffe3ffe6c0 (LWP 24226) "gmain"           0x00007ffff791fdef in poll () from /lib64/libc.so.6
  7    Thread 0x7fffe1dff6c0 (LWP 24229) "gdbus"           0x00007ffff791fdef in poll () from /lib64/libc.so.6
  8    Thread 0x7fffe09ff6c0 (LWP 24230) "glean.dispatche" 0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  9    Thread 0x7ffff275b6c0 (LWP 24232) "IPC I/O Parent"  0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  10   Thread 0x7ffff271a6c0 (LWP 24233) "Timer"           0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  11   Thread 0x7ffff26d96c0 (LWP 24234) "Netlink Monitor" 0x00007ffff791fdef in poll () from /lib64/libc.so.6
  12   Thread 0x7ffff26986c0 (LWP 24235) "Socket Thread"   0x00007ffff791fdef in poll () from /lib64/libc.so.6
  13   Thread 0x7ffff26576c0 (LWP 24236) "IPDL Background" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  14   Thread 0x7ffff23ff6c0 (LWP 24237) "Backgro~Pool #1" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  20   Thread 0x7ffff23866c0 (LWP 24252) "HTML5 Parser"    0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  21   Thread 0x7ffff1e986c0 (LWP 24253) "StyleThread#1"   0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  22   Thread 0x7ffff1b736c0 (LWP 24254) "StyleThread#2"   0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  23   Thread 0x7ffff1b326c0 (LWP 24255) "StyleThread#3"   0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  24   Thread 0x7ffff1af16c0 (LWP 24256) "StyleThread#4"   0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  25   Thread 0x7ffff1ab06c0 (LWP 24257) "StyleThread#5"   0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  28   Thread 0x7ffff23396c0 (LWP 24260) "JS Watchdog"     0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  30   Thread 0x7ffff12ff6c0 (LWP 24262) "Cache2 I/O"      0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  31   Thread 0x7ffff12be6c0 (LWP 24263) "Cookie"          0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  33   Thread 0x7fffd85ff6c0 (LWP 24265) "TaskCon~ller #0" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  34   Thread 0x7fffd84006c0 (LWP 24266) "TaskCon~ller #1" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  35   Thread 0x7fffd82016c0 (LWP 24267) "TaskCon~ller #2" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  36   Thread 0x7fffd80026c0 (LWP 24268) "TaskCon~ller #3" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  37   Thread 0x7fffd7e036c0 (LWP 24269) "TaskCon~ller #4" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  38   Thread 0x7fffd7c046c0 (LWP 24270) "TaskCon~ller #5" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  39   Thread 0x7fffd7a056c0 (LWP 24271) "TaskCon~ller #6" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  40   Thread 0x7fffd78066c0 (LWP 24272) "TaskCon~ller #7" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  41   Thread 0x7fffe5cff6c0 (LWP 24273) "BgIOThr~Pool #1" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  42   Thread 0x7fffe5cbe6c0 (LWP 24274) "Worker Launcher" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  43   Thread 0x7fffe5c7d6c0 (LWP 24275) "QuotaManager IO" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  44   Thread 0x7fffe4fff6c0 (LWP 24276) "Softwar~cThread" 0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  45   Thread 0x7fffe4aff6c0 (LWP 24277) "Renderer"        0x00007ffff78a3c1e in __futex_abstimed_wait_common () from /lib64/libc.so.6
  46   Thread 0x7fffdb6ff6c0 (LWP 24278) "WRWorker#0"      0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  47   Thread 0x7fffd69ff6c0 (LWP 24279) "WRWorker#1"      0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  48   Thread 0x7fffd67fe6c0 (LWP 24280) "WRWorker#2"      0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  49   Thread 0x7fffd62ff6c0 (LWP 24281) "WRWorker#3"      0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  50   Thread 0x7fffd5eff6c0 (LWP 24282) "WRWorkerLP#0"    0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  51   Thread 0x7fffd5aff6c0 (LWP 24283) "WRWorkerLP#1"    0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  52   Thread 0x7fffd56ff6c0 (LWP 24284) "WRWorkerLP#2"    0x00007ffff792bf99 in syscall () from /lib64/libc.so.6
  53   Thread 0x7fffd52ff6c0 (LWP 24285) "WRWorkerLP#3"    0x00007ffff792bf99 in syscall () from /lib64/libc.so.6

(gdb) print $rax
$1 = -516

(and yes, I installed -esr, so I could get the debug symbols)

42

If renaming .mozilla does not work, that in my view excludes the issue from extensions/plugins, unless it crashed only AFTER you re-installed some plugins/extension in firefox (after the old .mozilla removal) .

Do you have any unusual desktop themes in place? Do you have any unusual composition settings in place for your user’s desktop?

Given you claim another user on same PC does not have the same issue, and if a hypothetical (speculative) possibility that this issue is associated with your user’s configuration of KWin, is correct, then you could compare your desktop Compositor Rendering settings to that of the other user.

Along that line, some things to consider:

How different are your custom display scaling, DPI settings, or resolution that differs from that working user?

If using KDE Plasma, disable desktop effects or switch to a different compositor (again compare to the other user who has no issues).

Less likely are (IMHO) desktop themes but you you could still check your themes , font configurations and icon themes and compare with the user who has this working. My guess is this is highly unlikely to be the issue.

====

With regard to having the problem before you did the massive update, two thoughts.

While knowing you had the problem before, that does not mean knowing what you installed (to sort your desktop issues) is of no value. Second, I struggle imaging a scenario other than updates after an initial install, or not updating for a very very very long time, or your not making some massive change to your system could cause an output so big, that none of this can not be shared to help debug. I assume you would have told us if this was your 1st update, and I assume you would have told us if this was an update after none for a massive time, and I assume you would have told us that you changed something fundamental on your PC to cause the update.

What sort of update did you do that fixed your desktop crashes? (but unfortunately did not sort the problems of firefox)?

===

With regard to the strace … I can not decipher anything in that strace to make conclusion as to the issue. Perhaps others can.

Perhaps more information could help … if we can get any.

You could also check the journal to see if it might have any hints. Perhaps this (although the ‘firefox’ filter I suggest might be too tight and possibly you should look for something else).
sudo journalctl -p 0..3 --unit=user@licehunter | grep -i "firefox"
[In the above I am assuming user name is ’ licehunter ’ ] .

given ‘firefox’ may be wrong focus, perhaps this:
journalctl --user | grep -i "crash\|fault\|coredump\|segfault"

perhaps dmesg:
Or in dmesg look for this:
sudo dmesg -T --level=err,warn

I am grasping at straws a bit here - so pay attention to the suggestions of others.

43

Hi, appreciate your inputs. :smiling_face:

Nope. Bog standard:

I do not believe that to be the case. I am currently running a different user’s Firefox on my desktop and it is not crashing at all.

# Having created user `tempuser` …
# As user `licehunter` from my graphical session:
su -l tempuser
# tempuser>
firefox

From last night’s gdb session, it would appear that the crash is not actually in Firefox code but during a GLib call.

Given that the crash started spontaneously in the middle of a long-running (2‒3 weeks) desktop session and with no updates or new software having been installed either manually or automatically, my working hypothesis at the moment is that there was a change in my user environment that started triggering a latent issue, probably in GLib if not at a lower level.

It could be interesting to re-launch Firefox via su tempuser (minus the -l) see if that makes any difference—I’ll try that when I have the opportunity.

I’m going through the whole journalctl --user at the moment but I can’t spot anything unusual.

44

The idea was to compare your settings against the other user where you claim firefox works with no issues. I assume then this means you did and found no difference?

45

I am a bit puzzled by this as you previously stated in the following about updates:

Correct. must have been updated late yesterday or today. Either way, the problem started with 120-something and remained with 141.x.x.

…

I didn’t think to mention earlier, but for the last two weeks kwin does lock up badly every couple days or so, to the point that it only responds to kill 9.

…
KWin was locking up (only for myself) until I upgraded / rebooted / etc. yesterday (not saying it’s related)

On a separate note, I assume you rebooted since you have had these issues.

46

This , I think confirms, which most of us suspect, that there is something corrupted in your original user’s files/configuration or in your user’s /home/user environment. Baring any further information from dmesg or journal, I have no more ideas.

47

Correct. I said as much a few posts ago:

What I am doing now is trying to figure out what is it that’s causing trouble. I do not recall having done any intentional changes to the environment when the problem started, though I had been doing quite a bit of work involving WebGL and so.

If I can’t think of a better idea, I’ll probably end up cloning my $HOME, bit by bit until either it works or starts crashing. In the latter case, at least I’ll know what’s causing it.

48

Have you tried downloading FF and running it from there, do you understand how to do that
Just extract the archive to somewhere in your user area and click the firefox app

49

Why? (the “why” let’s the OP know the intent).

To me, doing this only creates a separate instance of the FF app. Once this installed executable is launched, it’s going to create [yet] another profile in the user’s “~/.mozilla” sub-directory tree (where their already-active profile(s) exist).
.
One troubleshooting step that has been done, is the OP installed the packaged Flatpak of FF from Discover app. The advantage of doing this is that a completely separate “.mozilla” sub-directory tree is created afresh down in the “~/.var/…” sub-dir tree (so the native “~/.mozilla” is not polluted with another profile entry). And of course, a completely separate executable is installed.

(The result of this troubleshooting step showed that the OP’s original problem still persisted).

1 Like
50

Quite correct.

51

OK - one final stab at this by me. These ideas are all highly speculative. And yes, they are ME speculating. Not some AI bot …

(a) You stated you went through your journal looking for issues. Are you 100% confident you did not miss anything?

(b) You could look for errors specific to your user (ie look for user space errors with the command):
sudo journalctl --user -b -1
The above will flood you with messages. perhaps focus mostly on those in yellow and red.

(c) You could examine your systemd journal for graphics-related errors in case that is the issue.
sudo journalctl -p 3 -b -1

(d) You could check to see if any desktop errors … which might show up if IMMEDIATELY AFTER A FIREFOX CRASH you use this to check:
cat ~/.xsession-errors

(e) I am curious as to what graphics you have on your PC, although that really should not be an issue. To show which graphics would could send the command:
inxi -G

(f) You could check for a system level library check that is affecting your user space and hence firefox (that is my wording ):
sudo zypper ve

Here are some very very very remote possible things to consider.

(1) a corruption in your user’s ~/.config folder. A drastic (temporary) check is to rename that to .config-back-up and then start firefox. Same problem? … do NOT forget to restore the ./config afterward. Again, this is a drastic check, but you could do this before moving to a new user account. This would be the VERY LAST thing I would try … and possibly only try this after I had another user account setup in case this goes bad.

(2) other remote possibilities are a corrupted .Xauthority … Ok - I am into big speculation here. I think to sort such a possibility, you would need to reboot to run level-3, at the full screen in level 3 login as your regular user. And type
mv ~/.Xauthority ~/.Xauthority.backup
then reboot.

If you do not want to boot from run level-3 you could, I suspect, instead , when in your GUI desktop logged in as your user, press Ctrl + Alt + F2 which will put you in a full screen text mode out of your graphic session. Then send:
mv ~/.Xauthority ~/.Xauthority.backup
then press Ctrl + Alt + F7 to get back to your graphical session and test firefox. However given you reported this:

Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Terminated

I can’t help but think this is not an .Xauthority issue but rather graphic related to your user’s environment. Still I mention this as a remote possibility.

(3) an issue with your SSD or HD affecting code related to the graphics stack, or something in your desktop environment. I would give this a 0.000001% chance of being the issue, but i am grasping at straws. You could check your drive (if for example it is sda) with a command such as:
sudo smartctl -H /dev/sda
.
however it is likely best to FIRST check first what is ‘system’ on your PC, looking for " / " and you can do that first by sending the command
lsblk
identify / and use that instead of ‘sda’ in my above example

(4) I am curious to see what repositories you have enabled, in case a repository you have installed is not a nominal one and might be introducing problems
zypper lr -d
Again - another ‘long shot’. It is more my curiosity - and likely won’t point to anything … still I wonder if there could be massive inappropriate repos setup
.
(5) another journal command to try:
sudo journalctl -k -b -1 | grep -i "nvidia\|error\|drm"
… the idea is to see if there are journal errors that might affect your user’s environment, but not the other user environment where you claim Firefox works. … AGAIN, this is a long shot !!

Again - there are MANY suggestions above, from myself.

Finally - You could instead, since you say another user does not have this problem, is simply create a new user, and copy over your files to that new user. Yes , it will take time to setup, but so is this debugging taking a lot of time.
.

52

A wall of text. Did you see that the wanted data for many of your questions are already provided in this thread? As example repolist and graphics data…

53

I did miss the inxi -GSazof the users (I spotted someone else’s post giving their example, so instead I mistakenly rejected that of the OP). I note now they have:

  Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 wm: kwin_x11 vt: 2
    dm: SDDM Distro: openSUSE Leap 15.6
Graphics:
  Device-1: AMD Renoir [Radeon Vega Series / Radeon Mobile Series]
    vendor: AIstone Global driver: amdgpu v: kernel arch: GCN-5 code: Vega
    process: GF 14nm built: 2017-20 pcie: gen: 4 speed: 16 GT/s lanes: 16
    ports: active: eDP-1 empty: HDMI-A-1 bus-ID: 04:00.0 chip-ID: 1002:1636
    class-ID: 0300 temp: 39.0 C

As for repos list. …yes … I’m bad there too. I saw the “search -si mesa” in their previous post but I missed their “zypper lr -d”. Strangely, it did not display until I scrolled more.

Looking now I note …
| mozilla | Mozilla based projects (openSUSE_Leap_15.6) | No | ---- | ---- | - | 99 | rpm-md | https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.6/ |

I have never fully trusted firefox there. Years ago i used to try to go for the latest mozilla , and I discovered that caused me more issues than it was worth. Having typed that - I think this could be an issue with firefox communication with graphic environment configured for this user. Will a different packaged firefox cause such? I don’t know.

I fail to see the user PRECISE report on journal… that i asked for. Perhaps you can point that to me in the “wall of text”

I fail to see the output of dmesg … asked earlier. Perhaps you can point that to me in the “wall of text”

I fail to see some other details ( such as xsession-errors ) - did I miss those also? Perhaps you can point that to me in the “wall of text”

Or is it your opinion that looking at dmesg, journal, xsession-errors a waste of time?

54

As mentioned previously, my current working hypothesis is that user profile corruption has occurred somewhere at some point. The ~/.config directory is one possible candidate indeed.

I do not want to zap the whole ~/.config at the moment as I’ve got a lot of stuff open that I’m working with, I’ll do so eventually though.

What I have done for the time being is started Firefox (under my own user’s profile, obviously) like this:

strace -e trace=open,openat,stat,lstat,access,read,write -f firefox 2>&1 | grep --color=auto "/.config"

As you can guess, the idea is to see what Firefox accesses within my profile (starting with ~/.config for now, then I can expand to other candidates) immediately prior to crashing. It sometimes crashes within seconds and other times it takes over a day, which makes troubleshooting a bit of a slow process though.

55

I hope you succeed.

This thread had me thinking … given the popularity of firefox, and that (in my view) reading of firefox crashes is fairly often - one would hope there was just one basic utility program that would run with various filters, that would automatically look for potential causes of the firefox crash and then provide the output to the user, to help them diagnose the problem. The script would be ONLY for firefox crash diagnosis.

I note in ~/.mozilla/firefox/Crash Reports/pending> is, I believe, where firefox crash reports are saved. However trying to interpet them is not all that easy. Further, those crash reports more often than not, likely do not have all the info one wants. The somenumber.extra files are readable with a text editor, but interpreting them is another matter. Further the somenumber.dmp are binary and are even more difficult to decipher and I have NOT tried there.

Out of curiosity - for my own interest, I created a basic script that can look at the files in ~/.mozilla/firefox/Crash Reports/pending> and do a bit of interpreting.

If curious about what I produced it can be downloaded with this command (which both downloads, places it in ~/local/bin and makes it executable).

wget -O "$HOME/.local/bin/firefoxcrash" https://termbin.com/ag8a && chmod +x "$HOME/.local/bin/firefoxcrash"

The “firecrash” script only looks. It saves nothing. After downloading one just types:
firefoxcrash

It is VERY VERY VERY basic.

It has me thinking I could attempt to ‘beef it up’ and put filtered input from journal , dmesg and possibly other output into such into the script. Having typed that, i am no programmer nor GNU/Linux expert - so I suspect anything I produce would likely be ripped to shreds by those ‘in the know’.

Still … having firefox crash is a real annoyance.

I recall constant random firefox crashes happened to me a many years back with my Lenovo X1 Carbon generation-9 , and it was a real annoyance to fix. The main cause was my hardware was too new, but there was, I recall, a workaround. However in my Lenovo’s case, all user accounts on my laptop had the crash (and not just my nominal user account) so I have not proposed what I did then (to sort the issue) on this thread.

Good luck.

56

Firefox has a built-in and external ways to inspect the crash report…no need to reinvent the wheel.

57

There is no crash data whatsoever from Firefox (and yes, crash reports are enabled).

Whatever it is, it’s a pretty brutal crash. I have an intuition that it occurs in GTK rather than Firefox code.

58

I tried to decode this that you provided:

--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=30032, si_uid=1000} ---
unlink("/home/licehunter/.mozilla/firefox/5kioifxe.default/lock") = 0
close(18)                               = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fcc5f857900}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TERM], NULL, 8) = 0
gettid()                                = 29376
getpid()                                = 29376
tgkill(29376, 29376, SIGTERM)           = 0
--- SIGTERM {si_signo=SIGTERM, si_code=SI_TKILL, si_pid=29376, si_uid=1000} ---
Exiting due to channel error.

In particular:

--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=30032, si_uid=1000} ---
SIGTERM

I read that is a standard software termination signal.

I also read:
si_code=SI_USER
This means the termination signal came from another user-space process, not the kernel nor a hardware fault.

Then:
si_pid=30032

I read this is the process that sent the termination signal.

Then
si_uid=1000
I read this is the user account (yours) that sent the signal (ie not root/system).

At least, that is how I interpret that.

I read:

Exiting due to channel error.
+++ killed by SIGTERM +++

That confirms Firefox was terminated … obviously … But perhaps that is what indicates why the termination did not occur in a manner to provide a Crash Report, which is supporting your observation.

So that SIGTERM indicates another process, running as the same user (uid=1000) which I believe is you, is killing Firefox with SIGTERM.

The above simply proves what you already have noted for sometime.

Except, perhaps, the process associated with the termination has PID 30032.

I do not know how to be able to identify that process long after the crash.

Possibly with ‘strace’ running … if you see that SIGTERM, and if you can immediately identify the PID (in my example 30032) that is killing firefox, you could run:
ps -fp 30032
That gives more detail to attempt to figure out what 30032 (in this example) is.

… or maybe it might be in the journal ? (wild speculation by me) :
sudo journalctl _PID=30032
or
sudo journalctl --user -b | grep 30032

of course each crash could have a different PID … so “30032” likely on each firefox termination it won’t be the same PID after a reboot.

I am still interested in the journal outputs, and I take it from your silence on this, with no replies to my suggestions there, that there was nothing interesting?

I could give more filters for journalctl but frankly, as noted, I suspect you are not interested in that line of journal in researching the problem, and you could be right. Possibly I am wrong about there being anything of value there in the journal. ( … but for myself, I have always found it of value).

An alternative approach to ‘strace’, to try to find the PID of a process that might be associated with killing firefox, you could try this audit rule (that monitors events), sending this BEFORE running firefox:
sudo auditctl -a exit,always -F arch=b64 -S kill

Then let firefox run. After firefox crashes, send this:

sudo ausearch -sc kill

The idea is that this may show all the kill-related syscalls that occurred, including any signals sent to terminate Firefox. If the crash is caused by another process , you’ll be able to see which process sent the signal.

Again, if only a PID # (such as 30032 in my example), then use
ps -fp 30032
or
sudo journalctl _PID=30032
or
sudo journalctl --user -b | grep 30032

Good luck!

1 Like
59

You know what? You may really be onto something here. Something that could turn out to be a very embarrassing mistake (but of course I will deny everything and do my very best to hide the evidence).

Let me check and I will get back to you and report.

60

Ok, I can confirm: there is nothing wrong with Firefox.

:person_facepalming:

The problem is that I am actually reviewing some code, on my account on this computer, and part of that code specifically looks for “idle” Firefox instances running as the same user and terminates them. That is what it is designed to do, and that is, unsurprisingly, what it does.

It is a fairly large code base and a part of it uses Firefox, driven by Selenium, to render complex PDF. Under normal circumstances, the Firefox instance should be shut down orderly by Selenium when it’s finished doing its job but there is a belt and braces watchdog that will kill any Firefoxes that are not being actively used by that code (which is designed to run on headless servers under its own user account, so no conflict with anything else).

Thank you everyone for your help and especially @oldcpu, whose most recent post correctly identified the issue. As someone trained in accident investigation and reporting, I should have known a lot better than jumping to conclusions and ignoring the evidence. I am grateful to @oldcpu for this humbling lesson.

1 Like