pcmanfm-qt crashes on 'heavy disk usage'

[Bluey26]

Expected Behavior

pcmanfm-qt should not restart/crash when hard disk usage ongoing.

Current Behavior

pcmanfm-qt seems to crash when i download several videos from internet, which does means a high disk usage(R/W operations).

Possible Solution

No idea.

Steps to Reproduce (for bugs)

I have no steps for this, but it usually happens to me when i download several videos from the web at the same time.

Context

After the report about system crashing, today i have found that pcmanfm-qt seems to crash to me, from time to time. This is an undesirable behavior because it closes all the folders i have opened. Fortunately the system does not crash, because the 'desktop' lxqt module seems to restart(background goes black for a moment, then wallpaper is loaded again).

I do not know the underlying causes for this, but i seem to be the only one having this issue.

I suspect this is somehow related to the lxqt-panel problem(something may have changed in archlinux packages lately), because coredumpctl list pcmanfm-qt shows the following:

TIME                                    PID   UID  GID      SIG     COREFILE          EXE    SIZE
Sat 2024-03-16 19:36:35  706 1000 1000 SIGSEGV present  /usr/bin/pcmanfm-qt 30.2M
Fri 2024-03-22 14:29:30   721 1000 1000 SIGSEGV present  /usr/bin/pcmanfm-qt 17.0M
Sun 2024-03-24 21:41:30 724 1000 1000 SIGSEGV present  /usr/bin/pcmanfm-qt  7.1M
Thu 2024-03-28 09:04:56 722 1000 1000 SIGSEGV present  /usr/bin/pcmanfm-qt  9.6M

This seems to be 2 weeks ago from today (In this issue: lxqt/lxqt-panel#2045 i have mentioned problems which have started 2weeks ago approximately).

Here is the last coredump, which have happened to me today. It was obtained with:

coredumpctl info pcmanfm-qt (timestamp removed and user/host parameters changed/removed).

           PID: 722 (pcmanfm-qt)
           UID: 1000 (USUARIO)
           GID: 1000 (USUARIO)
        Signal: 11 (SEGV)
        
  Command Line: /usr/bin/pcmanfm-qt --desktop --profile=lxqt
    Executable: /usr/bin/pcmanfm-qt
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (USUARIO)
       Storage: /var/lib/systemd/coredump/core.pcmanfm-qt.1000.54ce84df85754c5e83608d8f59f8c2cb.722.1711627493000000.zst (present)
  Size on Disk: 9.6M
       Message: Process 722 (pcmanfm-qt) of user 1000 dumped core.
                
                Stack trace of thread 133892:
                #0  0x0000725cf8cc8954 n/a (libQt5Core.so.5 + 0x2c8954)
                #1  0x0000725cf8aeb88a n/a (libQt5Core.so.5 + 0xeb88a)
                #2  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #3  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 769:
                #0  0x0000725cf83190bf __poll (libc.so.6 + 0xfb0bf)
                #1  0x0000725cf976c306 n/a (libglib-2.0.so.0 + 0xb9306)
                #2  0x0000725cf970c712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
                #3  0x0000725cf970c762 n/a (libglib-2.0.so.0 + 0x59762)
                #4  0x0000725cf973b065 n/a (libglib-2.0.so.0 + 0x88065)
                #5  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #6  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 848:
                #0  0x0000725cf82a5ebe n/a (libc.so.6 + 0x87ebe)
                #1  0x0000725cf82a8750 pthread_cond_wait (libc.so.6 + 0x8a750)
                #2  0x0000725cd888683c n/a (iris_dri.so + 0x8683c)
                #3  0x0000725cd889e7ec n/a (iris_dri.so + 0x9e7ec)
                #4  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #5  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 758:
                #0  0x0000725cf83190bf __poll (libc.so.6 + 0xfb0bf)
                #1  0x0000725cf9eb220b n/a (libxcb.so.1 + 0xd20b)
                #2  0x0000725cf9eb3f3d xcb_wait_for_event (libxcb.so.1 + 0xef3d)
                #3  0x0000725cf4ed50e2 n/a (libQt5XcbQpa.so.5 + 0x5d0e2)
                #4  0x0000725cf8aeb88a n/a (libQt5Core.so.5 + 0xeb88a)
                #5  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #6  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 770:
                #0  0x0000725cf83190bf __poll (libc.so.6 + 0xfb0bf)
                #1  0x0000725cf976c306 n/a (libglib-2.0.so.0 + 0xb9306)
                #2  0x0000725cf970ddc7 g_main_loop_run (libglib-2.0.so.0 + 0x5adc7)
                #3  0x0000725cf893c83c n/a (libgio-2.0.so.0 + 0x10983c)
                #4  0x0000725cf973b065 n/a (libglib-2.0.so.0 + 0x88065)
                #5  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #6  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 768:
                #0  0x0000725cf832488d syscall (libc.so.6 + 0x10688d)
                #1  0x0000725cf9767487 g_cond_wait (libglib-2.0.so.0 + 0xb4487)
                #2  0x0000725cf96d7454 n/a (libglib-2.0.so.0 + 0x24454)
                #3  0x0000725cf973c29e n/a (libglib-2.0.so.0 + 0x8929e)
                #4  0x0000725cf973b065 n/a (libglib-2.0.so.0 + 0x88065)
                #5  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #6  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 133237:
                #0  0x0000725cf82a5ebe n/a (libc.so.6 + 0x87ebe)
                #1  0x0000725cf82a8a65 pthread_cond_timedwait (libc.so.6 + 0x8aa65)
                #2  0x0000725cf8af35a4 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xf35a4)
                #3  0x0000725cf8af06da n/a (libQt5Core.so.5 + 0xf06da)
                #4  0x0000725cf8aeb88a n/a (libQt5Core.so.5 + 0xeb88a)
                #5  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #6  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 755:
                #0  0x0000725cf83190bf __poll (libc.so.6 + 0xfb0bf)
                #1  0x0000725cf976c306 n/a (libglib-2.0.so.0 + 0xb9306)
                #2  0x0000725cf970c712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
                #3  0x0000725cf8ce288c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2e288c)
                #4  0x0000725cf8c92774 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x292774)
                #5  0x0000725cf8aef666 _ZN7QThread4execEv (libQt5Core.so.5 + 0xef666)
                #6  0x0000725cfa098a9a n/a (libQt5DBus.so.5 + 0x17a9a)
                #7  0x0000725cf8aeb88a n/a (libQt5Core.so.5 + 0xeb88a)
                #8  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #9  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                
                Stack trace of thread 722:
                #0  0x0000725cf83190bf __poll (libc.so.6 + 0xfb0bf)
                #1  0x0000725cf976c306 n/a (libglib-2.0.so.0 + 0xb9306)
                #2  0x0000725cf970c712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
                #3  0x0000725cf8ce288c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2e288c)
                #4  0x0000725cf8c92774 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x292774)
                #5  0x0000725cf8c93c13 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x293c13)
                #6  0x0000603e217568e0 n/a (pcmanfm-qt + 0x258e0)
                #7  0x0000725cf8243cd0 n/a (libc.so.6 + 0x25cd0)
                #8  0x0000725cf8243d8a __libc_start_main (libc.so.6 + 0x25d8a)
                #9  0x0000603e217571b5 _start (pcmanfm-qt + 0x261b5)
                
                Stack trace of thread 847:
                #0  0x0000725cf82a5ebe n/a (libc.so.6 + 0x87ebe)
                #1  0x0000725cf82a8750 pthread_cond_wait (libc.so.6 + 0x8a750)
                #2  0x0000725cd888683c n/a (iris_dri.so + 0x8683c)
                #3  0x0000725cd889e7ec n/a (iris_dri.so + 0x9e7ec)
                #4  0x0000725cf82a955a n/a (libc.so.6 + 0x8b55a)
                #5  0x0000725cf8326a3c n/a (libc.so.6 + 0x108a3c)
                ELF object binary architecture: AMD x86-64

System Information

• PcManFm-qt version: pcmanfm-qt 1.4.1-1 (arch official repos)
• Distribution & Version: Archlinux; LXQt Version 1.4.0
• Qt Version: 5.15.13
• liblxqt Version: 1.4.0-1

Information which may help:

libfm-qt 1.4.0-3

AUR packages(may be outdated)

libfm-qt6-git 1.3.0.24.g0adb691-1
libqt6xdg-git 3.11.0.2.g77e4ccb-1

As @stefonarch suggested me, coredumpctl debug pcmanfm-qt would be more helpful than the coredump information. Unfortunately at the moment i only have limited internet connection, so i cannot download all the debug packages(some weight more than 100mb). I will run that command when i have normal internet back, but at least i tried to set the issue in here to you see if anything is wrong meanwhile.
I could be slow to answer because the internet issue.

Bluey.

[tsujan]

The cause of the crash doesn't seem to be in pcmanfm-qt itself. There's no trace of libfm-qt either.

This can be closed, but I'll wait until you attach what comes after coredumpctl gdb pcmanfm-qt then where

[Bluey26]

Here is the output of:

coredumpctl gdb pcmanfm-qt

[Thread debugging using libthread_db enabled]                                                                                                        
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/pcmanfm-qt --desktop --profile=lxqt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  std::__atomic_base<QObjectPrivate::Connection*>::load (__m=std::memory_order_relaxed, this=0x20) at /usr/include/c++/13.2.1/atomic:576
576           load(memory_order __m = memory_order_seq_cst) const noexcept
[Current thread is 1 (Thread 0x725ccdc006c0 (LWP 133892))]

And this is what is obtained after running where inside gdb:

(gdb) where
#0  std::__atomic_base<QObjectPrivate::Connection*>::load (__m=std::memory_order_relaxed, this=0x20) at /usr/include/c++/13.2.1/atomic:576
#1  std::atomic<QObjectPrivate::Connection*>::load (__m=std::memory_order_relaxed, this=0x20) at /usr/include/c++/13.2.1/atomic:577
#2  QAtomicOps<QObjectPrivate::Connection*>::loadRelaxed<QObjectPrivate::Connection*>
    (_q_value=<error reading variable: Cannot access memory at address 0x20>) at ../../include/QtCore/../../src/corelib/thread/qatomic_cxx11.h:239
#3  QBasicAtomicPointer<QObjectPrivate::Connection>::loadRelaxed (this=0x20) at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:248
#4  QObjectPrivate::ConnectionData::cleanOrphanedConnections
    (lockPolicy=QObjectPrivate::ConnectionData::NeedToLock, sender=0x603e237bbcc0, this=0x0) at kernel/qobject_p.h:292
#5  doActivate<false> (sender=0x603e237bbcc0, signal_index=4, argv=0x725ccdbffd00) at kernel/qobject.cpp:3967
#6  0x0000725cf8aeb88a in operator() (__closure=<optimized out>) at thread/qthread_unix.cpp:350
#7  (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=<optimized out>) at thread/qthread_unix.cpp:287
#8  QThreadPrivate::start (arg=0x725c98002f30) at thread/qthread_unix.cpp:310
#9  0x0000725cf82a955a in start_thread (arg=<optimized out>) at pthread_create.c:447
#10 0x0000725cf8326a3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

[tsujan]

Thanks! The backtrace doesn't show any problem in pcmanfm-qt itself.

The root of the problem should be much deeper.

[tsujan]

This seems to be 2 weeks ago from today (In this issue: lxqt/lxqt-panel#2045 i have mentioned problems which have started 2weeks ago approximately).

Although none of LXQt components shows any problem here, whether under X11 or under Wayland, I can say that something has changed for me too for 2-3 weeks. I've encountered total system freezes due to kernel oops with kernels 6.6 and 6.8 alike. Apparently, the freezes happen only after I log out from a Wayland session and log into an X11 session, or conversely.

I'm not saying that the problems you've encountered are related to mine — especially because they seem very different — but if you find any clue, please tell me. Total system freezes have been reported recently in Arch and Manjaro, but after hours of searching the Internet, I didn't find a common cause.