| Summary: | Plasmashell crashes in Solid::Backends::Fstab::FstabHandling::_k_updateMtabMountPointsCache() when turning on the monitor | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-solid | Reporter: | Matthias Fabinski <matthias.fab> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | kdelibs-bugs, lukas, nate |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 6.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| 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 | ||
|
Description
Matthias Fabinski
2024-08-08 06:06:56 UTC
Created attachment 172389 [details]
New crash information added by DrKonqi
DrKonqi auto-attaching complete backtrace.
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? 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
Looks like a very carefully curated /etc/fstab file! `coredumpctl` should be able to tell you when the crash happened. 🐛🧹 ⚠️ 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! 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 Thanks a lot for following up! |