Created attachment 174494 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.

searchable backtrace


Thread 1 (Thread 0x7ff74f4006c0 (LWP 64333)):
[KCrash Handler]
#5  std::__atomic_base<int>::fetch_add (this=<optimized out>, __i=1, __m=std::memory_order::acq_rel) at /usr/include/qt6/QtCore/qbasicatomic.h:47
#6  QAtomicOps<int>::ref<int> (_q_value=<optimized out>) at /usr/include/qt6/QtCore/qatomic_cxx11.h:259
#7  QBasicAtomicInteger<int>::ref (this=<optimized out>) at /usr/include/qt6/QtCore/qbasicatomic.h:47
#8  QArrayData::ref (this=<optimized out>, this=<optimized out>) at /usr/include/qt6/QtCore/qarraydata.h:58
#9  QArrayDataPointer<char16_t>::ref (this=0x7ff74f3ff1f0) at /usr/include/qt6/QtCore/qarraydatapointer.h:438
#10 QArrayDataPointer<char16_t>::QArrayDataPointer (this=0x7ff74f3ff1f0, other=<optimized out>) at /usr/include/qt6/QtCore/qarraydatapointer.h:40
#11 QString::QString (this=0x7ff74f3ff1f0, other=<optimized out>, this=<optimized out>, other=<optimized out>) at /usr/include/qt6/QtCore/qstring.h:1186
#12 Solid::DevicePrivate::udi (this=<optimized out>) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/frontend/device_p.h:32
#13 Solid::Device::udi (this=this@entry=0x7ff8140897e8) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/frontend/device.cpp:70
#14 0x00007ff8197662d8 in operator() (__closure=<optimized out>, device=...) at /usr/src/debug/kf6-kio-6.6.0-1.fc40.x86_64/src/filewidgets/kfileplacesmodel.cpp:744
#15 __gnu_cxx::__ops::_Iter_pred<KFilePlacesModelPrivate::deviceRemoved(const QString&)::<lambda(const Solid::Device&)> >::operator()<QList<Solid::Device>::iterator> (this=<optimized out>, __it=...) at /usr/include/c++/14/bits/predefined_ops.h:318
#16 std::__find_if<QList<Solid::Device>::iterator, __gnu_cxx::__ops::_Iter_pred<KFilePlacesModelPrivate::deviceRemoved(const QString&)::<lambda(const Solid::Device&)> > > (__first=..., __last=..., __pred=...) at /usr/include/c++/14/bits/stl_algobase.h:2109
#17 std::__find_if<QList<Solid::Device>::iterator, __gnu_cxx::__ops::_Iter_pred<KFilePlacesModelPrivate::deviceRemoved(const QString&)::<lambda(const Solid::Device&)> > > (__first=..., __last=..., __pred=...) at /usr/include/c++/14/bits/stl_algobase.h:2142
#18 std::find_if<QList<Solid::Device>::iterator, KFilePlacesModelPrivate::deviceRemoved(const QString&)::<lambda(const Solid::Device&)> > (__first=..., __last=..., __pred=...) at /usr/include/c++/14/bits/stl_algo.h:3875
#19 KFilePlacesModelPrivate::deviceRemoved (this=0x7ff720001640, udi=<optimized out>) at /usr/src/debug/kf6-kio-6.6.0-1.fc40.x86_64/src/filewidgets/kfileplacesmodel.cpp:743
#20 operator() (__closure=<optimized out>, device=<optimized out>) at /usr/src/debug/kf6-kio-6.6.0-1.fc40.x86_64/src/filewidgets/kfileplacesmodel.cpp:723
#21 QtPrivate::FunctorCall<QtPrivate::IndexesList<0>, QtPrivate::List<const QString&>, void, KFilePlacesModelPrivate::initDeviceList()::<lambda(const QString&)> >::call (f=<optimized out>, arg=<optimized out>) at /usr/include/qt6/QtCore/qobjectdefs_impl.h:137
#22 QtPrivate::FunctorCallable<KFilePlacesModelPrivate::initDeviceList()::<lambda(const QString&)>, const QString&>::call<QtPrivate::List<QString const&>, void> (f=<optimized out>, arg=<optimized out>) at /usr/include/qt6/QtCore/qobjectdefs_impl.h:345
#23 QtPrivate::QCallableObject<KFilePlacesModelPrivate::initDeviceList()::<lambda(const QString&)>, QtPrivate::List<const QString&>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt6/QtCore/qobjectdefs_impl.h:555
#24 0x00007ff82d9fc8f2 in QtPrivate::QSlotObjectBase::call (this=0x7ff720018c20, r=<optimized out>, a=0x7ff74f3ff330) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobjectdefs_impl.h:469
#25 doActivate<false> (sender=0x7ff720029a20, signal_index=4, argv=0x7ff74f3ff330) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobject.cpp:4086
#26 0x00007ff82d9f2bc7 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7ff8306157a0 <Solid::DeviceNotifier::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7ff74f3ff330) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobject.cpp:4146
#27 0x00007ff830571bac in Solid::DeviceNotifier::deviceRemoved (this=<optimized out>, _t1=<optimized out>) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/redhat-linux-build/src/solid/KF6Solid_autogen/include/moc_devicenotifier.cpp:162
#28 0x00007ff82d9fc8f2 in QtPrivate::QSlotObjectBase::call (this=0x7ff72000a960, r=<optimized out>, a=0x7ff74f3ff540) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobjectdefs_impl.h:469
#29 doActivate<false> (sender=0x7ff720066160, signal_index=4, argv=0x7ff74f3ff540) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobject.cpp:4086
#30 0x00007ff82d9f2bc7 in QMetaObject::activate (sender=sender@entry=0x7ff720066160, m=m@entry=0x7ff830615ea0 <Solid::Ifaces::DeviceManager::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7ff74f3ff540) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobject.cpp:4146
#31 0x00007ff8305cc5d2 in Solid::Ifaces::DeviceManager::deviceRemoved (this=0x7ff720066160, _t1=...) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/redhat-linux-build/src/solid/KF6Solid_autogen/include/moc_devicemanager.cpp:162
#32 Solid::Backends::Fstab::FstabManager::_k_updateDeviceList (this=this@entry=0x7ff720066160) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/backends/fstab/fstabmanager.cpp:123
#33 0x00007ff8305ccfdb in Solid::Backends::Fstab::FstabManager::onMtabChanged (this=0x7ff720066160) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/backends/fstab/fstabmanager.cpp:132
#34 0x00007ff82d9eddcb in QObject::event (this=0x7ff720066160, e=0x7ff8140dc170) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qobject.cpp:1452
#35 0x00007ff82fd8b218 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x7ff720066160, e=0x7ff8140dc170) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/widgets/kernel/qapplication.cpp:3287
#36 0x00007ff82d996e88 in QCoreApplication::notifyInternal2 (receiver=0x7ff720066160, event=0x7ff8140dc170) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1142
#37 0x00007ff82d9970ed in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1583
#38 0x00007ff82d99ac51 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x555eeb22fc30) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1940
#39 0x00007ff82d99aefd in QCoreApplication::sendPostedEvents (receiver=<optimized out>, event_type=<optimized out>) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1797
#40 0x00007ff82dc859ef in postEventSourceDispatch (s=0x7ff720000f20) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:244
#41 0x00007ff82c478e8c in g_main_dispatch (context=0x7ff720000c60) at ../glib/gmain.c:3344
#42 g_main_context_dispatch_unlocked (context=0x7ff720000c60) at ../glib/gmain.c:4152
#43 0x00007ff82c4dac98 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x7ff720000c60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4217
#44 0x00007ff82c47a383 in g_main_context_iteration (context=0x7ff720000c60, may_block=1) at ../glib/gmain.c:4282
#45 0x00007ff82dc851a3 in QEventDispatcherGlib::processEvents (this=0x7ff720000b70, flags=...) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:394
#46 0x00007ff82d9a3bc3 in QEventLoop::exec (this=this@entry=0x7ff74f3ffa70, flags=..., flags@entry=...) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/global/qflags.h:34
#47 0x00007ff82dab7f4f in QThread::exec (this=<optimized out>) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/global/qflags.h:74
#48 0x00007ff82db5473c in operator() (__closure=<optimized out>) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/thread/qthread_unix.cpp:326
#49 (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=<optimized out>) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/thread/qthread_unix.cpp:262
#50 QThreadPrivate::start (arg=0x555ee826d4f0) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.x86_64/src/corelib/thread/qthread_unix.cpp:285
#51 0x00007ff82d2a66d7 in start_thread (arg=<optimized out>) at pthread_create.c:447
#52 0x00007ff82d32a60c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Do you have anything like network drive in your fstab file? Seems the crash is caused by something in there:


#12 Solid::DevicePrivate::udi (this=<optimized out>) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/frontend/device_p.h:32
#13 Solid::Device::udi (this=this@entry=0x7ff8140897e8) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/frontend/device.cpp:70
...
#32 Solid::Backends::Fstab::FstabManager::_k_updateDeviceList (this=this@entry=0x7ff720066160) at /usr/src/debug/kf6-solid-6.6.0-1.fc40.x86_64/src/solid/devices/backends/fstab/fstabmanager.cpp:123

*** Bug 493664 has been marked as a duplicate of this bug. ***

Yes I do!
I can remove that to see if that helps!

That would explain it. :) 

It's better to use Dolphin's network folder management for adding such folders. If you add them directly to fstab, it can confuse the system.

Nate, did you have a wiki page for this somewhere?

There are valid reasons users might want to have a network mount via /etc/fstab
My own use case is that most music players don't see Samba or nfs folders unless they are mounted locally (they need to see a local folder)
Wouldn't it be better to update the code to be able to work with fstab? (We obviously can't control the behavior of all software to make them all samba/nfs aware)

The problem is that there is an infinite amount of code in KDE software that assumes things that show up as local files won't randomly become transient. Changing all of it is not only an impossible 20 year project, it would likely reduce performance due to the need to check for whether mounts hasn't gone stale.

At least the KDE apps should be updated to be able to find files using the KIO workers. This is a much smaller and more feasible project.

For third-party apps that can't or won't use KIO, a better solution is to encourage people to make use of kio-fuse for this by accessing their shares in Dolphin, and then we change kio-fuse to do the FUSE mount in a persistent, unchanging location. Then we also allow it to be automounted on login, optionally. This would give us the best of both worlds.

If I remember right, that is what my goal was, to automatically  mount the share at login.

🐛🧹 ⚠️ 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!

.

(In reply to Nate Graham from comment #8)
> The problem is that there is an infinite amount of code in KDE software that
> assumes things that show up as local files won't randomly become transient.
The problem is that KDE (or more to the point, solid) constantly mucks about in "local" filesystems the user isn't actively accessing, and has no graceful handling for those background i/o operations failing.

A program freezing or crashing when a filesystem the user is currently interacting with (using said program) goes down is expected and largely unavoidable. The whole desktop (or every open file manager window, i.e. the many, many bug reports regarding dolphin and network mounts) doing the same when a filesystem that _isn't_ currently displayed in any window or being accessed by the user is not expected, and furthermore, it's a behaviour that appears to be unique to KDE.


> For third-party apps that can't or won't use KIO, a better solution is to
> encourage people to make use of kio-fuse for this by accessing their shares
> in Dolphin, and then we change kio-fuse to do the FUSE mount in a
> persistent, unchanging location. Then we also allow it to be automounted on
> login, optionally. This would give us the best of both worlds.
It'll also mean that network mounts are reliant on KIO, unreasonably slow (FUSE), only available after login, and (without further manual configuration) only available to a specific user. That's the best of _one_ world - namely a single-user GUI desktop, where that GUI is always KDE.

There are many reasons to mount network shares early in the boot process and at a level below KDE/KIO, and such has been normal practice on every unix for decades. This was never a problem until KDE with its "everything integrated with everything else" design and incessant polling of every available filesystem became involved.

*** Bug 497022 has been marked as a duplicate of this bug. ***

> Definitely the same backtrace. Maybe network mounts are a red herring. Can you paste your /etc/fstab file into Bug 494224 please? Thanks!

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sdc2
UUID=fe827356-7ea9-4e1a-8e6f-553d1240a549	/         	xfs       	rw,relatime,inode64,logbufs=8,logbsize=32k,noquota0 1

# /dev/sdc1
UUID=ABB4-2B04      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/sda1
UUID=8fd3d246-ad34-42c0-8011-776f2fbdb3e9	/home     	xfs       	rw,relatime,inode64,logbufs=8,logbsize=32k,noquota0 2
UUID=fa1e9ffa-4871-482c-870e-af19ece782ff	/data     	xfs       	rw,relatime,inode64,logbufs=8,logbsize=32k,noquota0 2
UUID=49874016-ae3f-40d2-9ce5-bcd476e686b4	/fastdata     	xfs       	rw,relatime,inode64,logbufs=8,logbsize=32k,noquota0 2

I forgot to add - even though I don't have any unusual mounts in fstab the installation process I linked to in the duplicate bug does make you setup a loop mount 
losetup --partscan /dev/loop1 chromeos_15393.58.0_reven_recovery_stable-channel_mp-v2.bin

But this time I think I got a different back trace - reported here as bug 497299