Firefox crashes during each upgrade

Hi all,

I have a strange problem since a few months. The problem is that most times when I run an update or installation of a package, Firefox crashes. It mostly happens after the system was suspended, I can’t see a reproducible pattern. It doesn’t need the suspend to crash but it makes it more likely.

I don’t remember if it started at some point or if it was already the case for this new laptop that I have, so it could be from kernel 6.1 up until 6.8, and any mesa updates that happened in between (both official and nonfree). I’m on the unstable branch.

Typically, I have two Firefox sessions running (one work profile, one private profile) and at least one of them crashes with Firefox telling me that it crashed, sometimes both. The about:crashes page is full with sent reports.

There is nothing in the journal or dmesg.

However, I guess it’s a Firefox problem, not a Manjaro problem :frowning:

inxi -Fazy
System:
  Kernel: 6.7.5-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc avail: hpet,acpi_pm parameters: amd_pstate=active
    vt.default_red=30,243,166,249,137,245,148,186,88,243,166,249,137,245,148,166
    vt.default_grn=30,139,227,226,180,194,226,194,91,139,227,226,180,194,226,173
    vt.default_blu=46,168,161,175,250,231,213,222,112,168,161,175,250,231,213,200
    nowatchdog quiet loglevel=3 systemd.show_status=0 rd.udev.log_level=3
    bgrt_disable root=/dev/mapper/root
    rd.luks.name=0de0c664-9e72-4586-8cb9-5d277a20f167=root
    rootflags=subvol=@,x-systemd.device-timeout=0 rw
    rd.luks.options=discard,no-read-workqueue,no-write-workqueue,timeout=0
    lsm=landlock,lockdown,yama,integrity,apparmor,bpf apparmor=1 audit=0
    resume=/dev/mapper/root resume_offset=691710
  Desktop: i3 v: 4.23 with: i3bar tools: xss-lock avail: i3lock vt: 7
    dm: LightDM v: 1.32.0 Distro: Manjaro base: Arch Linux
Machine:
  Type: Laptop System: HP product: HP EliteBook 845 14 inch G10 Notebook PC
    v: SBKPF serial: <superuser required> Chassis: type: 10
    serial: <superuser required>
  Mobo: HP model: 8B6E v: KBC Version 60.28.00 serial: <superuser required>
    part-nu: 818N0EA#ABD uuid: <superuser required> UEFI: HP v: 82 Ver. 01.03.09
    date: 12/11/2023
Battery:
  ID-1: BAT0 charge: 47.0 Wh (100.0%) condition: 47.0/51.3 Wh (91.6%)
    volts: 12.9 min: 11.6 model: Hewlett-Packard Primary type: Li-ion
    serial: <filter> status: full cycles: 53
CPU:
  Info: model: AMD Ryzen 9 PRO 7940HS w/ Radeon 780M Graphics bits: 64
    type: MT MCP arch: Zen 4 gen: 5 level: v4 note: check built: 2022+
    process: TSMC n5 (5nm) family: 0x19 (25) model-id: 0x74 (116) stepping: 1
    microcode: 0xA704104
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 8 MiB desc: 8x1024 KiB
    L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 571 high: 2154
    min/max: 400/5583:5263:5743:6228:6067:5903:5423 scaling:
    driver: amd-pstate-epp governor: powersave cores: 1: 400 2: 400 3: 400
    4: 2154 5: 400 6: 400 7: 400 8: 400 9: 1397 10: 400 11: 400 12: 400 13: 400
    14: 400 15: 400 16: 400 bogomips: 127818
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow mitigation: Safe RET
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
    prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Enhanced / Automatic IBRS, IBPB: conditional,
    STIBP: always-on, RSB filling, PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Phoenix1 vendor: Hewlett-Packard driver: amdgpu v: kernel
    arch: RDNA-3 code: Phoenix process: TSMC n4 (4nm) built: 2023+ pcie: gen: 4
    speed: 16 GT/s lanes: 16 ports: active: DP-6,HDMI-A-1,eDP-1 empty: DP-1,
    DP-2, DP-3, DP-4, DP-5, DP-7 bus-ID: c3:00.0 chip-ID: 1002:15bf
    class-ID: 0300 temp: 48.0 C
  Device-2: Luxvisions Innotech HP 5MP Camera driver: uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-1:2 chip-ID: 30c9:0096
    class-ID: fe01 serial: <filter>
  Device-3: Logitech HD Webcam C525 driver: snd-usb-audio,uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 9-1:2 chip-ID: 046d:0826
    class-ID: 0e02 serial: <filter>
  Display: x11 server: X.Org v: 21.1.11 compositor: Picom v: git-89c2c
    driver: X: loaded: amdgpu unloaded: modesetting alternate: fbdev,vesa
    dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
  Screen-1: 0 s-res: 7040x1600 s-dpi: 96 s-size: 1861x423mm (73.27x16.65")
    s-diag: 1908mm (75.14")
  Monitor-1: DP-6 mapped: DisplayPort-5 pos: primary,center
    model: Acer EB321HQU serial: <filter> built: 2016 res: 2560x1440 hz: 60
    dpi: 93 gamma: 1.2 size: 699x393mm (27.52x15.47") diag: 802mm (31.6")
    ratio: 16:9 modes: max: 2560x1440 min: 720x400
  Monitor-2: HDMI-A-1 mapped: HDMI-A-0 pos: left model: Samsung SyncMaster
    serial: <filter> built: 2010 res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2
    size: 477x268mm (18.78x10.55") diag: 547mm (21.5") ratio: 16:9 modes:
    max: 1920x1080 min: 640x480
  Monitor-3: eDP-1 mapped: eDP pos: right model: AU Optronics 0x6da8
    built: 2022 res: 2560x1600 hz: 120 dpi: 216 gamma: 1.2
    size: 301x188mm (11.85x7.4") diag: 355mm (14") ratio: 16:10 modes:
    max: 2560x1600 min: 640x480
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi x11: drv: radeonsi
    inactive: gbm
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.1-arch10.1
    glx-v: 1.4 direct-render: yes renderer: AMD Radeon Graphics (radeonsi
    gfx1103_r1 LLVM 16.0.6 DRM 3.57 6.7.5-1-MANJARO) device-ID: 1002:15bf
    memory: 500 MiB unified: no
Audio:
  Device-1: AMD Rembrandt Radeon High Definition Audio driver: snd_hda_intel
    v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16 bus-ID: c3:00.1
    chip-ID: 1002:1640 class-ID: 0403
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Hewlett-Packard
    driver: snd_pci_ps v: kernel alternate: snd_pci_acp3x, snd_rn_pci_acp3x,
    snd_pci_acp5x, snd_pci_acp6x, snd_acp_pci, snd_rpl_pci_acp6x,
    snd_sof_amd_renoir, snd_sof_amd_rembrandt, snd_sof_amd_vangogh,
    snd_sof_amd_acp63 pcie: gen: 4 speed: 16 GT/s lanes: 16 bus-ID: c3:00.5
    chip-ID: 1022:15e2 class-ID: 0480
  Device-3: AMD Family 17h/19h HD Audio vendor: Hewlett-Packard
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: c3:00.6 chip-ID: 1022:15e3 class-ID: 0403
  Device-4: Logitech HD Webcam C525 driver: snd-usb-audio,uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 9-1:2 chip-ID: 046d:0826
    class-ID: 0e02 serial: <filter>
  Device-5: Texas Instruments PCM2912A Audio Codec driver: snd-usb-audio
    type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 9-4:3
    chip-ID: 08bb:2912 class-ID: 0102
  API: ALSA v: k6.7.5-1-MANJARO status: kernel-api
    tools: alsactl,alsamixer,amixer
  Server-1: PipeWire v: 1.0.3 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8852CE PCIe 802.11ax Wireless Network
    vendor: Hewlett-Packard driver: rtw89_8852ce v: kernel pcie: gen: 2
    speed: 5 GT/s lanes: 1 port: a000 bus-ID: 01:00.0 chip-ID: 10ec:c852
    class-ID: 0280
  IF: wlp1s0 state: up mac: <filter>
  Device-2: Intel I210 Gigabit Network driver: igb v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 66:00.0 chip-ID: 8086:1533
    class-ID: 0200
  IF: enp102s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: docker0 state: down mac: <filter>
  IF-ID-2: wg-ghoofybox state: down mac: N/A
  IF-ID-3: wg-ottobeuren state: down mac: N/A
  Info: services: systemd-networkd, systemd-timesyncd, wpa_supplicant
Bluetooth:
  Device-1: Realtek Bluetooth Radio driver: btusb v: 0.8 type: USB rev: 1.0
    speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-3:2 chip-ID: 0bda:c85c
    class-ID: e001 serial: <filter>
  Report: btmgmt ID: hci0 rfk-id: 5 state: down bt-service: enabled,running
    rfk-block: hardware: no software: no address: <filter> bt-v: 5.3 lmp-v: 12
    status: discoverable: yes pairing: yes
Drives:
  Local Storage: total: 953.87 GiB used: 375.55 GiB (39.4%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: SanDisk model: SK hynix PC801
    HFS001TEJ9X101N size: 953.87 GiB block-size: physical: 512 B logical: 512 B
    speed: 63.2 Gb/s lanes: 4 tech: SSD serial: <filter> fw-rev: HPS1
    temp: 45.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 953.32 GiB size: 953.32 GiB (100.00%)
    used: 373.4 GiB (39.2%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0 mapped: root
  ID-2: /boot raw-size: 550 MiB size: 548.9 MiB (99.80%)
    used: 97.2 MiB (17.7%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 953.32 GiB size: 953.32 GiB (100.00%)
    used: 373.4 GiB (39.2%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0 mapped: root
Swap:
  Kernel: swappiness: 10 (default 60) cache-pressure: 75 (default 100)
    zswap: yes compressor: zstd max-pool: 20%
  ID-1: swap-1 type: file size: 32 GiB used: 9.1 MiB (0.0%) priority: -2
    file: /swap/swapfile
Sensors:
  System Temperatures: cpu: N/A mobo: N/A gpu: amdgpu temp: 57.0 C
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 32 GiB note: est. available: 30.63 GiB used: 17.44 GiB (56.9%)
  Processes: 455 Power: uptime: 1d 1h 51m states: freeze,mem,disk
    suspend: s2idle wakeups: 4 hibernate: platform avail: shutdown, reboot,
    suspend, test_resume image: 12.22 GiB services: power-profiles-daemon,
    upowerd, xfce4-power-manager Init: systemd v: 255 default: graphical
    tool: systemctl
  Packages: 1637 pm: pacman pkgs: 1622 libs: 308
    tools: pacseek,pamac,paru,yay pm: flatpak pkgs: 15 Compilers: clang: 16.0.6
    gcc: 13.2.1 Shell: Zsh v: 5.9 running-in: tmux: inxi: 3.3.33

:point_down:

1 Like

Meh, yeah thanks, but this also happens for updating flatpaks or installing any random package.

I don’t use any FlatPaks, but I always close all windows — except for a terminal window — when updating individual packages. :man_shrugging:

Really? Also when you install a new package (let’s say yq)?

Yes, absolutely. The only thing open is a terminal window.

Does this include a fresh default profile?

Yes, any kind of Firefox process. I can’t fully reproduce every time, so testing different configurations is exhaustive.

When you install a package using pamac gui - the default is to update the system as well.

If your installation coincides an update of something firefox is using - or firefox itself is updated - then yes - firefox may crash.

I haven’t seen a crash - but with firefox being open when updated - I have seen a message from firefox saying - you need to close and reopen.

Generally, firefox does not crash when updated while running. It will show a “restart required” when opening a new tab or window.

This happens for installing any package; not specifically glibc or the firefox itself.

sudo pacman -S jq (as an example) will cause it. sudo pacman -Syu jq will cause it, doesn’t matter if anything else was updated or not.

Quite strange - I just tested - installing the jq package - no crashes - Firefox 122.0.1

I cannot grasp why it would - I am completely tefloned

This is over my head, but something about reloading udev rules:

Proposed workaround was

sudo touch /etc/systemd/do-not-udevadm-trigger-on-update

Thanks, it doesn’t crash if I run the hooks manually.

Do you, by chance, know if these hooks are also run when I install/update flatpak packages? I maybe thought about it being the gtk-application cache or something else (mime types?), which is updated by libalpm and flatpak.

Do not ever suspend after an update (without rebooting) !

The kernel and the modules used to start your system (and to suspend it) may be not present in the same binary form any more when you try to resume.

:footprints:

2 Likes

You mean hibernate but it crashes during the update, not after waking up.

Firefox normally will complain and ask to be restarted after updates.
I update it while open all the time and thats the result … it looks normal enough until you try to load a new page or something and then it will say it ‘needs to restart to finish up’ or something similar.

If yours behaves differently then I must assume its some sort of issue.

firefox --safe-mode

?

The idea that its ‘update any package and firefox crashes’ … might speak to something else like … you have the profile running in TMPFS plus your RAM is full? Or something?

With relation to the idea proposed at the Arch BBS in mind - am I understanding it correct - you can consistently trigger the crash - by running pacman -Syu <pkgname> as described?

So it must be a hook common for Arch and Manjaro - right?

And since it is not happening for my Manjaro system (unstable branch) - we should look for differences - right?

I can share a list of files from my frankenjaro-station (Manjaro Plasma 6.0 RC2)

 $ tree /usr/share/libalpm
/usr/share/libalpm
├── hooks
│   ├── 20-systemd-sysusers.hook
│   ├── 30-systemd-binfmt.hook
│   ├── 30-systemd-catalog.hook
│   ├── 30-systemd-daemon-reload-system.hook
│   ├── 30-systemd-daemon-reload-user.hook
│   ├── 30-systemd-hwdb.hook
│   ├── 30-systemd-sysctl.hook
│   ├── 30-systemd-tmpfiles.hook
│   ├── 30-systemd-udev-reload.hook
│   ├── 30-systemd-update.hook
│   ├── 30-update-mime-database.hook
│   ├── 40-fontconfig-config.hook
│   ├── 40-update-ca-trust.hook
│   ├── 60-depmod.hook
│   ├── 60-mkinitcpio-remove.hook
│   ├── 70-dkms-install.hook
│   ├── 70-dkms-upgrade.hook
│   ├── 71-dkms-remove.hook
│   ├── 80-cronie.hook
│   ├── 90-mkinitcpio-install.hook
│   ├── 90-packagekit-refresh.hook
│   ├── 90-update-appstream-cache.hook
│   ├── 99-update-grub.hook
│   ├── dbus-reload.hook
│   ├── dconf-update.hook
│   ├── detect-old-perl-modules.hook
│   ├── fontconfig-32.hook
│   ├── fontconfig.hook
│   ├── gdk-pixbuf-query-loaders-32.hook
│   ├── gdk-pixbuf-query-loaders.hook
│   ├── ghc-register.hook
│   ├── ghc-unregister.hook
│   ├── gio-querymodules-32.hook
│   ├── gio-querymodules.hook
│   ├── glib-compile-schemas.hook
│   ├── gtk4-querymodules.hook
│   ├── gtk-query-immodules-2.0.hook
│   ├── gtk-query-immodules-3.0.hook
│   ├── gtk-update-icon-cache.hook
│   ├── gvfsd.hook
│   ├── manjaro-printer.hook
│   ├── networkmanager-connectivity.hook
│   ├── pacman-mirrors-install.hook
│   ├── pacman-mirrors-upgrade.hook
│   ├── texinfo-install.hook
│   ├── texinfo-remove.hook
│   ├── update-desktop-database.hook
│   └── update-vlc-plugin-cache.hook
└── scripts
    ├── 40-fontconfig-config
    ├── dconf-update
    ├── depmod
    ├── detect-old-perl-modules.sh
    ├── dkms
    ├── gtk4-querymodules
    ├── gtk-update-icon-cache
    ├── hide_menu_entries
    ├── mkinitcpio
    ├── pacman-mirrors-install
    ├── pacman-mirrors-upgrade
    └── systemd-hook

All hooks has an **Exec= ** - in theory - systematically executing those commands in root context should at some point make firefox crash - right?

On my laptop running Arch Linux

/usr/share/libalpm
├── hooks
│   ├── 20-systemd-sysusers.hook
│   ├── 30-systemd-binfmt.hook
│   ├── 30-systemd-catalog.hook
│   ├── 30-systemd-daemon-reload-system.hook
│   ├── 30-systemd-daemon-reload-user.hook
│   ├── 30-systemd-hwdb.hook
│   ├── 30-systemd-sysctl.hook
│   ├── 30-systemd-tmpfiles.hook
│   ├── 30-systemd-udev-reload.hook
│   ├── 30-systemd-update.hook
│   ├── 30-update-mime-database.hook
│   ├── 40-fontconfig-config.hook
│   ├── 40-update-ca-trust.hook
│   ├── 60-depmod.hook
│   ├── 60-mkinitcpio-remove.hook
│   ├── 90-mkinitcpio-install.hook
│   ├── 90-packagekit-refresh.hook
│   ├── 90-update-appstream-cache.hook
│   ├── dbus-reload.hook
│   ├── dconf-update.hook
│   ├── detect-old-perl-modules.hook
│   ├── fontconfig.hook
│   ├── gdk-pixbuf-query-loaders.hook
│   ├── gio-querymodules.hook
│   ├── glib-compile-schemas.hook
│   ├── gtk-query-immodules-3.0.hook
│   ├── gtk-update-icon-cache.hook
│   ├── update-desktop-database.hook
│   ├── update-vlc-plugin-cache.hook
│   ├── xorg-mkfontscale.hook
│   └── zz-sbctl.hook
└── scripts
    ├── 40-fontconfig-config
    ├── dconf-update
    ├── depmod
    ├── detect-old-perl-modules.sh
    ├── gtk-update-icon-cache
    ├── mkinitcpio
    ├── systemd-hook
    └── xorg-mkfontscale

To automate such test - one could extract these commands

 $ grep -hn "Exec = " /usr/share/libalpm/hooks/ | awk -F' = ' '{print $2}'
/usr/share/libalpm/scripts/systemd-hook udev-reload
/usr/bin/env PKGSYSTEM_ENABLE_FSYNC=0 /usr/bin/update-mime-database /usr/share/mime
/usr/bin/gdk-pixbuf-query-loaders --update-cache
/usr/share/libalpm/scripts/hide_menu_entries
/usr/share/libalpm/scripts/dkms install
/usr/share/libalpm/scripts/systemd-hook hwdb
/usr/share/libalpm/scripts/mkinitcpio remove
/usr/share/libalpm/scripts/systemd-hook tmpfiles
/usr/share/libalpm/scripts/detect-old-perl-modules.sh
/bin/sh -c 'while read -r f; do if test -f "$f"; then install-info "$f" /usr/share/info/dir 2> /dev/null; fi; done'
/usr/share/libalpm/scripts/gtk4-querymodules
/bin/sh -c 'gdbus call --system --timeout 30 --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --method org.freedesktop.PackageKit.StateHasChanged posttrans > /dev/null'
/usr/bin/update-ca-trust
/usr/share/libalpm/scripts/systemd-hook update
/usr/share/libalpm/scripts/dkms -D remove
/usr/bin/systemctl try-restart cronie.service
/bin/sh -c 'while read -r f; do /bin/sh "/$f" >>/var/log/haskell-register.log 2>&1 ; done'
/usr/share/libalpm/scripts/systemd-hook reload dbus
/usr/share/libalpm/scripts/systemd-hook daemon-reload-system
/bin/bash -c 'sed -i -e "s!^uri=.*!uri=http://ping.manjaro.org/check_network_status.txt!g" /usr/lib/NetworkManager/conf.d/20-connectivity.conf'
/usr/bin/gio-querymodules-32 /usr/lib32/gio/modules
/usr/bin/appstreamcli refresh-cache --force
/usr/share/libalpm/scripts/dconf-update
/usr/bin/gio-querymodules /usr/lib/gio/modules
/usr/share/libalpm/scripts/systemd-hook sysctl
/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas
/usr/bin/gtk-query-immodules-3.0 --update-cache
/usr/lib/vlc/vlc-cache-gen /usr/lib/vlc/plugins
/usr/share/libalpm/scripts/pacman-mirrors-upgrade
/usr/share/libalpm/scripts/systemd-hook daemon-reload-user
/usr/share/libalpm/scripts/systemd-hook catalog
/usr/share/libalpm/scripts/dkms remove
/usr/bin/fc-cache-32 -s
/usr/share/libalpm/scripts/mkinitcpio install
/usr/share/libalpm/scripts/systemd-hook sysusers
/usr/share/libalpm/scripts/40-fontconfig-config /etc/fonts/conf.d
/usr/bin/fc-cache -s
/usr/share/libalpm/scripts/depmod
/usr/bin/update-desktop-database --quiet
/usr/share/libalpm/scripts/systemd-hook binfmt
/usr/bin/gtk-query-immodules-2.0 --update-cache
/usr/share/libalpm/scripts/pacman-mirrors-install
/usr/share/libalpm/scripts/gtk-update-icon-cache
/bin/sh -c 'while read -r f; do install-info --delete "$f" /usr/share/info/dir 2> /dev/null; done'
/usr/bin/gdk-pixbuf-query-loaders-32 --update-cache
/bin/sh -c 'while read -r f; do /bin/sh "/$f" >>/var/log/haskell-register.log 2>&1 ; done'
/bin/sh -c 'killall -q -s USR1 gvfsd || true'
/usr/bin/update-grub

The suggestion by @cscs is quite good

To reduce wear and tear on SSD there is the profile-sync-daemon

Arch and Manjaro contains the hook for reloading tmp files, so perhaps this command may trigger the crash

│   ├── 30-systemd-tmpfiles.hook
/usr/share/libalpm/scripts/systemd-hook tmpfiles

A largely overblown concern.
But the possible speed improvements make it worth consideration.
(I generally do use PSD, though I’ve found on faster machines I dont need it)

I also think checking hooks is a good idea for this issue.

Thanks for your input. The profile is not on a tmpfs or ramdisk but it’s cache (browser.cache.disk.parent_directory) is on a mounted ramdisk.
I will test it further, however, I don’t know how to test it properly because the crash is not always triggered.

Yes, however, not every time. It doesn’t matter if using pamac (cli or gui), pacman, paru or yay.

What wonders me especially is that also flatpak updates can cause this. There must be some shared hook.

So not consistent - but often?

Do you update flatpak using Pamac? For what I know - flatpak does not trigger pacman hooks.

If you are using Pamac to update flatpak it makes sense that some interference is generated - after all Pamac also requires elevated privileges to install flatpak.

I just tested installing Telegram Desktop - I updated my system to Plasma 6 and the repo version stopped working - and I had no firefox crashes - just as I haven’t been able to confirm your crashing report.

Have you tried the suggesting to trigger the commands extracted - one at a time to see if you can provoke a crash?