Bug 491422 - Plasmashell crashes in Solid::Backends::Fstab::FstabHandling::_k_updateMtabMountPointsCache() when turning on the monitor
Summary: Plasmashell crashes in Solid::Backends::Fstab::FstabHandling::_k_updateMtabMo...
Status: RESOLVED WORKSFORME
Alias: None
Product: frameworks-solid
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 6.4.0
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2024-08-08 06:06 UTC by Matthias Fabinski
Modified: 2024-09-05 11:19 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report: https://crash-reports.kde.org/organizations/kde/issues/56011/events/d1fb7999788849d2aeedbdadf211a926/


Attachments
New crash information added by DrKonqi (136.65 KB, text/plain)
2024-08-08 06:06 UTC, Matthias Fabinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Fabinski 2024-08-08 06:06:56 UTC
Application: plasmashell (6.1.3)

Qt Version: 6.7.2
Frameworks Version: 6.4.0
Operating System: Linux 6.10.2-arch1-2 x86_64
Windowing System: Wayland
Distribution: "Arch Linux"
DrKonqi: 6.1.3 [CoredumpBackend]

-- Information about the crash:
This crash happens some times, when I turn on one of my monitors (2x 4K LG). I don't know how to reproduce it, but it happens frequently.

This time only one Monitor was configured, and as i started this monitor, the crash info was shown. 

Currently only 1 Monitor is set.


Operating System: Arch Linux 
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.10.2-arch1-2 (64-bit)
Graphics Platform: Wayland
Processors: 24 ร— AMD Ryzen 9 3900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 5700 XT

The reporter is unsure if this crash is reproducible.

-- Backtrace (Reduced):
#6  0x0000710589c9fa39 in Solid::Backends::Fstab::FstabHandling::_k_updateMtabMountPointsCache () at /usr/src/debug/solid/solid-6.4.0/src/solid/devices/backends/fstab/fstabhandling.cpp:364
#7  0x0000710589ca1615 in Solid::Backends::Fstab::FstabHandling::_k_updateMtabMountPointsCache () at /usr/src/debug/solid/solid-6.4.0/src/solid/devices/backends/fstab/fstabhandling.cpp:330
#8  Solid::Backends::Fstab::FstabHandling::deviceList () at /usr/src/debug/solid/solid-6.4.0/src/solid/devices/backends/fstab/fstabhandling.cpp:235
#9  0x0000710589c9a449 in Solid::Backends::Fstab::FstabManager::_k_updateDeviceList (this=this@entry=0x710330ffce30) at /usr/src/debug/solid/solid-6.4.0/src/solid/devices/backends/fstab/fstabmanager.cpp:107
#10 0x0000710589c9b94c in Solid::Backends::Fstab::FstabManager::onMtabChanged (this=0x710330ffce30) at /usr/src/debug/solid/solid-6.4.0/src/solid/devices/backends/fstab/fstabmanager.cpp:132


Reported using DrKonqi
Comment 1 Matthias Fabinski 2024-08-08 06:06:57 UTC
Created attachment 172389 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.
Comment 2 Nate Graham 2024-08-09 04:22:52 UTC
Solid::Backends::Fstab::FstabHandling::_k_updateMtabMountPointsCache is a funny place for it to crash if it's truly monitor-related. Can you verify that your /etc/fstab file looks okay and is free of obvious errors, file corruption, etc?
Comment 3 Matthias Fabinski 2024-08-10 07:21:03 UTC
Hello, thanks for looking into it.

I assumed it is monitor related, because i only see the message after turning on the monitor after longer time of keeping the system running, but with monitor turned off.

Is it possible to find the time of the crash in order to correlate, if the bug occured at the time of turning on the monitor, or if it happened during the night?

All my mounts in the fstab work, i'm unsure, if there are some obvious errors. 

> ## /dev/sdc1
> #UUID=3eb51d00-a1c6-4ba5-8e05-636eacb8c9b4      /               ext4            rw,defaults,noatime,discard   0 1
> 
> ## /dev/sdc2
> #UUID=77299e97-ec88-48b7-938a-ae5017b4b9d0      none            swap            defaults,noatime,discard      0 0
> 
> # /dev/sda1
> # Festplatte old UUID=A2DCE3A1DCE36E4B                          /mnt/fun        ntfs-3g      defaults,uid=1000,rw,nofail      0 0
> # ssd:
> UUID=DxxxxxxxxxxxxxxC                           /mnt/fun        ntfs-3g         defaults,uid=1000,rw,nofail   0 0
> 
> # /dev/sdf1
> UUID=fxxxxxxx-bxx7-4xx6-9xxc-axxxxxxxxxx4       /mnt/backup     ext4            rw,defaults,nofail,x-systemd.device-timeout=1,noauto,x-systemd.automount      0 0
> 
> # toshiba ext
> UUID=4xxxxxxxxxxxxxx5                           /mnt/text       ntfs-3g         defaults,uid=1000,rw,nofail,noauto    0 0
> 
> # big backup
> UUID=7xxxxxxxxxxxxxxA                           /mnt/bigbackup  ntfs-3g         defaults,uid=1000,rw,nofail,noauto      0 0
> 
> ### old fstab above ####
> 
> # /dev/nvme0n1p1
> UUID=4xxxxxxa-axxa-4xx5-9xx7-6xxxxxxxxxx6       /               ext4            rw,relatime  0 1
> 
> //xxxx.home/lexmark        /mnt/lexmark    cifs    defaults,nofail,username=matthias,password=notmyrealpw,x-systemd.automount,x-systemd.requires=network-online.target,uid=1000,file_mode=0644,dir_mode=0755  0 0
> //xxxx.home/gemeinsam      /mnt/gemeinsam  cifs    defaults,nofail,username=matthias,password=notmyrealpw,x-systemd.automount,x-systemd.requires=network-online.target,uid=1000,file_mode=0644,dir_mode=0755  0 0
> //xxxx.home/matthias       /mnt/matthias   cifs    defaults,nofail,username=matthias,password=notmyrealpw,x-systemd.automount,x-systemd.requires=network-online.target,uid=1000,file_mode=0644,dir_mode=0755  0 0
> //xxxx.home/multimedia     /mnt/multimedia cifs    defaults,nofail,username=matthias,password=notmyrealpw,x-systemd.automount,x-systemd.requires=network-online.target,uid=1000,file_mode=0644,dir_mode=0755  0 0
> //xxxx.home/syncthing      /mnt/syncthing  cifs    defaults,nofail,username=matthias,password=notmyrealpw,x-systemd.automount,x-systemd.requires=network-online.target,uid=1000,file_mode=0644,dir_mode=0755  0 0

I can give more logs etc. but don't know where to look for. 

Kind regards,
Matthias
Comment 4 Nate Graham 2024-08-13 22:29:07 UTC
Looks like a very carefully curated /etc/fstab file!

`coredumpctl` should be able to tell you when the crash happened.
Comment 5 Bug Janitor Service 2024-08-28 03:47:40 UTC
๐Ÿ›๐Ÿงน โš ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Matthias Fabinski 2024-09-05 07:16:50 UTC
Hello Nate,
thanks again for looking into this.
The coredump did not occur to me in the resent weeks and i could not find a way to reproduce it. In Coredumpctl i've seen, that the bug occured way before i turned the monitors on, so it is unrelated to this.
Therefore i think, this bug can be closed as "WORKSFORME" - sorry for the noise.
Kind regards
Matthias
Comment 7 Nate Graham 2024-09-05 11:19:17 UTC
Thanks a lot for following up!