SUMMARY When attempting to put my laptop into sleep or hibernate, I return to the lockscreen but the GUI is completely unresponsive and does not even update the time. When I switch to a new console, and check dmesg, I see multiple stack traces for baloo_file. See below for example. Disable baloo with balootctl6 does not change the outcome. STEPS TO REPRODUCE 1. Attempt to put system into sleep or hibernate OBSERVED RESULT [Sun Sep 22 23:06:34 2024] task:baloo_file state:D stack:0 pid:1036 tgid:1036 ppid:944 flags:0x00004006 [Sun Sep 22 23:06:34 2024] Call Trace: [Sun Sep 22 23:06:34 2024] <TASK> [Sun Sep 22 23:06:34 2024] __schedule+0x3d5/0x1520 [Sun Sep 22 23:06:34 2024] schedule+0x27/0xf0 [Sun Sep 22 23:06:34 2024] request_wait_answer+0xd0/0x2b0 [Sun Sep 22 23:06:34 2024] ? __pfx_autoremove_wake_function+0x10/0x10 [Sun Sep 22 23:06:34 2024] fuse_simple_request+0x17e/0x2c0 [Sun Sep 22 23:06:34 2024] fuse_readdir_uncached+0x17e/0x840 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? dput+0x2f/0x1b0 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? fuse_file_open+0xe4/0x1a0 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? mntput_no_expire+0x4a/0x260 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] iterate_dir+0x121/0x220 [Sun Sep 22 23:06:34 2024] __x64_sys_getdents64+0x86/0x130 [Sun Sep 22 23:06:34 2024] ? __pfx_filldir64+0x10/0x10 [Sun Sep 22 23:06:34 2024] do_syscall_64+0x82/0x190 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? __rseq_handle_notify_resume+0xa6/0x490 [Sun Sep 22 23:06:34 2024] ? do_sys_openat2+0x9c/0xe0 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? syscall_exit_to_user_mode+0x72/0x200 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? do_syscall_64+0x8e/0x190 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? __slab_free+0xdf/0x2f0 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? __slab_free+0xdf/0x2f0 [Sun Sep 22 23:06:34 2024] ? __memcg_slab_free_hook+0xf7/0x140 [Sun Sep 22 23:06:34 2024] ? __x64_sys_close+0x3c/0x80 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? kmem_cache_free+0x3a0/0x400 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? syscall_exit_to_user_mode+0x72/0x200 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? do_syscall_64+0x8e/0x190 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? __rseq_handle_notify_resume+0xa6/0x490 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? switch_fpu_return+0x4e/0xd0 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? syscall_exit_to_user_mode+0x72/0x200 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? do_syscall_64+0x8e/0x190 [Sun Sep 22 23:06:34 2024] ? switch_fpu_return+0x4e/0xd0 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? syscall_exit_to_user_mode+0x72/0x200 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] ? do_syscall_64+0x8e/0x190 [Sun Sep 22 23:06:34 2024] ? srso_alias_return_thunk+0x5/0xfbef5 [Sun Sep 22 23:06:34 2024] entry_SYSCALL_64_after_hwframe+0x76/0x7e [Sun Sep 22 23:06:34 2024] RIP: 0033:0x7621788f1137 [Sun Sep 22 23:06:34 2024] RSP: 002b:00007fff971bf4f8 EFLAGS: 00000293 ORIG_RAX: 00000000000000d9 [Sun Sep 22 23:06:34 2024] RAX: ffffffffffffffda RBX: 0000601a0c1c57a0 RCX: 00007621788f1137 [Sun Sep 22 23:06:34 2024] RDX: 0000000000008000 RSI: 0000601a0c1c57d0 RDI: 000000000000000f [Sun Sep 22 23:06:34 2024] RBP: 00007fff971bf530 R08: 0000601a0c0e6c50 R09: 0000000000000000 [Sun Sep 22 23:06:34 2024] R10: 0000000000000000 R11: 0000000000000293 R12: 0000601a0c1c57a4 [Sun Sep 22 23:06:34 2024] R13: 0000601a0c1c57d0 R14: fffffffffffffeb8 R15: 0000000000000002 [Sun Sep 22 23:06:34 2024] </TASK> EXPECTED RESULT Laptop would be able to enter sleep or hibernate and exit without having to reboot system SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.10.10-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 PRO 7840HS w/ Radeon 780M Graphics Memory: 30.0 GiB of RAM Graphics Processor: AMD Radeon 780M Storage: BTRFS on Luks + Encrypted SWAP partion ADDITIONAL INFORMATION Even disabling baloo, my system shows this stack trace after it locks up.
Disabling baloo and rebooting seems to be the workaround as I am now able to sleep and hibernate and recover my system without rebooting. I did find https://discuss.kde.org/t/baloo-file-extractor-constantly-crashes/18616 which looks partially related, though the crash only happens for me when I sleep or hibernate.
(In reply to Randall Larson from comment #1) > Disabling baloo and rebooting seems to be the workaround as I am now able to > sleep and hibernate and recover my system without rebooting. I did find > https://discuss.kde.org/t/baloo-file-extractor-constantly-crashes/18616 > which looks partially related, though the crash only happens for me when I > sleep or hibernate. That ought to be "history" now... It is interesting that it is "baloo_file" crashing and not "baloo_file_extractor", the latter does the heavy lifting of getting the plain text out of the various format files. That is more often the source of trouble. I have two guesses... Baloo's index has got just plain "too large". I might say that's reasonably likely as you are running on BTRFS. Check how big your ~/.local/share/baloo/index file is.... Second option is that Baloo is swapping. That's not something that you want... The actual impact on the system depends on whether Baloo is running under systemd or not - there is a kde-baloo unit file that sets a limit on memory usage.
(In reply to tagwerk19 from comment #2) > Baloo's index has got just plain "too large". I might say that's reasonably likely as you are running on BTRFS. Check how big your > ~/.local/share/baloo/index file is.... (Sorry new to Bugzilla so not sure if I can use markdown formatting) $ ls -lh .local/share/baloo/index -rw-r--r-- 1 <USER> <GROUP> 2.6M Sep 22 22:45 .local/share/baloo/index I am using btrfs, but the index file does not seem _that_ big, but I am also not familiar with the inner workings of Baloo. I've noticed this crash happens when its in the process of attempting to index files on my fusemount (rclone to MS OneDrive). Right now, it does seem to be "hung" when trying to index a photo of type .heic. For the short term, I will disable indexing of my fusemount, but is it _expected_ that it hang on .heic files?
(In reply to Randall Larson from comment #3) Excluding .heic allowed indexing to not become hung on those file types, but hibernate/sleep is still problematic when indexing my fuse mount. I suspect there may be two bugs happening here, though the latter is more disruptive for a laptop.
(In reply to Randall Larson from comment #3) > $ ls -lh .local/share/baloo/index > -rw-r--r-- 1 <USER> <GROUP> 2.6M Sep 22 22:45 .local/share/baloo/index > > I am using btrfs, but the index file does not seem _that_ big .... No, that's not big. You should start worrying when it gets as big as your available RAM (as a very, very approximate measure) > ... I've noticed this crash > happens when its in the process of attempting to index files on my fusemount > (rclone to MS OneDrive). Right now, it does seem to be "hung" when trying > to index a photo of type .heic. For the short term, I will disable indexing > of my fusemount, but is it _expected_ that it hang on .heic files? Well, you can try copying the .heic to a non-fusemounted folder or you can get a test sample. I tend to go to https://filesamples.com/ You can try doing the indexing in the foreground, with: $ balooctl index sample1.heic and check what's been extracted with $ balooshow -x sample1.heic (Possibly with balooctl6 and balooshow6 rather than balooctl and balooshow) I'm still a little suspicious that it is baloo_file failing and not baloo_file_extractor. If there was an issue reading or extracting the metadata, it would be the extractor crashing...