Bug 502141

Could you see if the following patch helps?


diff --git a/src/plugins/sfdisk/sfdiskbackend.cpp b/src/plugins/sfdisk/sfdiskbackend.cpp
index e47c4e5..2fe99dd 100644
--- a/src/plugins/sfdisk/sfdiskbackend.cpp
+++ b/src/plugins/sfdisk/sfdiskbackend.cpp
@@ -515,6 +515,8 @@ bool SfdiskBackend::updateDevicePartitionTable(Device &d, const QJsonObject &jso
 */
 void SfdiskBackend::readSectorsUsed(const Device& d, Partition& p, const QString& mountPoint)
 {
+    if (p.isFileSystemNullptr())
+        return;
     if (!mountPoint.isEmpty() && p.fileSystem().type() != FileSystem::Type::LinuxSwap && p.fileSystem().type() != FileSystem::Type::Lvm2_PV) {
         const QStorageInfo storage = QStorageInfo(mountPoint);
         if (p.isMounted() && storage.isValid())

Thank you! That does fix the crash, but then it gets stuck at "Scanning device: '/dev/sdb/' ".

Created attachment 179830 [details]
Stuck here now with that patch applied

If it's related, I see this in the log output:

unknown file system type  "dos"  on  "/dev/sdb"

(and yes, it is ostensibly FAT32-formatted)

(In reply to Nate Graham from comment #4)
> If it's related, I see this in the log output:
> 
> unknown file system type  "dos"  on  "/dev/sdb"

That might be just checking whether it is full disk FAT partition... MBR has somewhat similar signature.
Do you know if that USB has partition table or is it full disk filesystem?

I guess the following info could be useful
lsblk /dev/sdb
udevadm info --query=property /dev/sdb
udevadm info --query=property /dev/sdb1 (if it has partition table)

Perhaps you could also obtain backtrace from the stuck instance? Right now I have no idea where it is stuck.

Created attachment 179831 [details]
Output of those commands

I do notice that what's stuck is a spawned /usr/libexec/kpmcore_externalcommand process. If I quit the app, that keeps going. I'll try to get backtraces of both.

App is stuck here:

#0  0x00007ffff4cf4370 in __GI_ppoll
    (fds=fds@entry=0xc62a60, nfds=nfds@entry=1, timeout=<optimized out>, 
    timeout@entry=0x7fffffffcd00, sigmask=sigmask@entry=0x0)
    at ../sysdeps/unix/sysv/linux/ppoll.c:42
#1  0x00007ffff498e8a3 in ppoll (__fds=0xc62a60, __nfds=1, __timeout=0x7fffffffcd00, __ss=0x0)
    at /usr/include/bits/poll2.h:101
#2  g_main_context_poll_unlocked
    (priority=<optimized out>, context=0x7fffdc000f00, timeout_usec=<optimized out>, fds=0xc62a60, n_fds=1) at ../glib/gmain.c:4591
#3  g_main_context_iterate_unlocked.isra.0
    (context=context@entry=0x7fffdc000f00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4268
#4  0x00007ffff492f783 in g_main_context_iteration (context=0x7fffdc000f00, may_block=1)
    at ../glib/gmain.c:4338
#5  0x00007ffff55ef2b3 in QEventDispatcherGlib::processEvents (this=0x4d07a0, flags=...)
    at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:399
#6  0x00007ffff5300993 in QEventLoop::exec (this=this@entry=0x7fffffffce70, flags=..., 
    flags@entry=...)
    at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/global/qflags.h:34
#7  0x00007ffff52fbf6e in QCoreApplication::exec ()
    at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/global/qflags.h:74
#8  0x00007ffff5ad7d3d in QGuiApplication::exec ()
    at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/gui/kernel/qguiapplication.cpp:1975
#9  0x00007ffff643d929 in QApplication::exec ()
    at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/widgets/kernel/qapplication.cpp:2564
#10 0x0000000000406b2c in main (argc=<optimized out>, argv=<optimized out>)
    at /home/nate/kde/src/partitionmanager/src/main.cpp:143





externalcommand process is stuck here:

#0  0x00007fcd674f4370 in ppoll () at /lib64/libc.so.6
#1  0x00007fcd679518a3 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
#2  0x00007fcd678f2783 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007fcd67def2b3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6Core.so.6
#4  0x00007fcd67b00993 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /lib64/libQt6Core.so.6
#5  0x00007fcd67afbf6e in QCoreApplication::exec() () at /lib64/libQt6Core.so.6
#6  0x000055939ab83a4a in main ()

(In reply to Nate Graham from comment #9)
> I do notice that what's stuck is a spawned
> /usr/libexec/kpmcore_externalcommand process. If I quit the app, that keeps
> going. I'll try to get backtraces of both.

That's kind of intentional, it tries to finish current task rather than killing it to reduce chance of data loss.

Hmm, I can't tell much from these two backtraces, looks like it's just in the even loop. Perhaps running it with KPMCORE_DEBUG=y ./partitionmanager would print which command it's attempting to run?

Created attachment 179834 [details]
Debug output

It appears to be running `fsck.fat -n -v /dev/sdc1`. I'm attaching the full debug output.

(In reply to Nate Graham from comment #12)
> Created attachment 179834 [details]
> Debug output
> 
> It appears to be running `fsck.fat -n -v /dev/sdc1`. I'm attaching the full
> debug output.

Hmm, does that also get stuck when running manually? Not sure how we can detect this automatically.

Anyway, I think the crash fixed can be pushed.

Crash fixed pushed to https://invent.kde.org/system/kpmcore/-/commit/458ef81f2e424f13cdea44d2d89b8260b463e34e

If I run the command by hand, it appears to find approximately ten trillion issues inside /.Spotlight-V100/Store-V2/C64039E9-5043-4001-B62F-51236F7144F9/journals.live_priority/FSCK0000.000, like this:

/.Spotlight-V100/Store-V2/C64039E9-5043-4001-B62F-51236F7144F9/journals.live_priority/FSCK0000.000/0áw0
  Bad short file name (0áw0).
  Auto-renaming it.
  Renamed to FSCK0002.427
/.Spotlight-V100/Store-V2/C64039E9-5043-4001-B62F-51236F7144F9/journals.live_priority/FSCK0000.000/╩3░Ö0┬!.:Ö
  Bad short file name (╩3░Ö0┬!.:Ö).
  Auto-renaming it.
  Renamed to FSCK0002.428
/.Spotlight-V100/Store-V2/C64039E9-5043-4001-B62F-51236F7144F9/journals.live_priority/FSCK0000.000/O@ÉÖüÆa.
  Bad short file name (O@ÉÖüÆa.).
  Auto-renaming it.
  Renamed to FSCK0002.429
/.Spotlight-V100/Store-V2/C64039E9-5043-4001-B62F-51236F7144F9/journals.live_priority/FSCK0000.000/K@0¾üÜ .ó!
  Bad short file name (K@0¾üÜ .ó!).
  Auto-renaming it.
  Renamed to FSCK0002.430


Endless amount of this. It's very strange because that's something that would be created by a MacOS machine, and to my knowledge this disk has never touched a Mac. It's the external storage disk on my 3D printer.

So I guess the command is doing what it should, though it's... just never finishing. Maybe eventually if I let it run for hours or something, it might finish!

It appears to be super duper corrupted. It won't mount read/write, only RO. My intention was to use Partition Manager to erase it, but I can't since it runs this never-ending fsck on launch.

(In reply to Nate Graham from comment #16)
> It appears to be super duper corrupted. It won't mount read/write, only RO.
> My intention was to use Partition Manager to erase it, but I can't since it
> runs this never-ending fsck on launch.

Hmm, I didn't expect fsck on boot but it looks like specifically for FAT fsck.vfat -n -v is used to read Used Space:
https://invent.kde.org/system/kpmcore/-/blob/master/src/fs/fat12.cpp?ref_type=heads#L113

I guess the proper fix would be to add timeout option to this command.

As a quick hack return -1; at the beginning of that function should unblock you.

Or maybe just a cancel button in case a process hangs.

The crash is fixed; closing as resolved now. :) I'll let you ponder over if and how to address the other issues brought up here. Thanks a lot for the rapid response!

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

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

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

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

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

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

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

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

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