Random freezes

[ManuelSchneid3r]

There are several reports that seem to have the same cause. Random freezes. Since it does not crash, coredumps are not helpful. If you want to help, post a log (pastebin please) showing this kind of freezes.

Findings:

albert/src/query/globalqueryexecution.cpp

Line 211 in 897c779

d->future_watcher.waitForFinished();

Blocks forever. Its difficult to tell why it does so. I noticed that disabling the python plugin seems to make this problem vanish. 🤷‍♂️

[devdave]

i can replicate the lockup reliably via "docs Python API" or "docs Rustfmt" and I have gdb breakpoints set but it doesn't make sense what I am seeing,

(gdb) bt
#0  0x00007ffff7498d71 in __futex_abstimed_wait_common64 (private=1076232192, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5555562675f0) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=1076232192, abstime=0x0, clockid=0, expected=0, futex_word=0x5555562675f0) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555562675f0, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007ffff749b7ed in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555562675a0, cond=0x5555562675c8) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x5555562675c8, mutex=0x5555562675a0) at ./nptl/pthread_cond_wait.c:627
#5  0x00007ffff6076c03 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#6  0x00007ffff6081067 in QFutureInterfaceBase::waitForFinished() () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#7  0x00007ffff7cf86fd in GeneratorQueryHandlerExecution::~GeneratorQueryHandlerExecution (this=0x5555571e8d70, __in_chrg=<optimized out>) at /home/devdave/projects/albert/src/query/generatorqueryhandler.cpp:62
#8  0x00007ffff7cf876a in GeneratorQueryHandlerExecution::~GeneratorQueryHandlerExecution (this=0x5555571e8d70, __in_chrg=<optimized out>) at /home/devdave/projects/albert/src/query/generatorqueryhandler.cpp:64
#9  0x00007ffff7d17cc4 in std::default_delete<albert::QueryExecution>::operator() (this=0x555556267590, __ptr=0x5555571e8d70) at /usr/include/c++/13/bits/unique_ptr.h:99
#10 0x00007ffff7d17d28 in std::__uniq_ptr_impl<albert::QueryExecution, std::default_delete<albert::QueryExecution> >::reset (this=0x555556267590, __p=0x0) at /usr/include/c++/13/bits/unique_ptr.h:211
#11 0x00007ffff7d17a1b in std::unique_ptr<albert::QueryExecution, std::default_delete<albert::QueryExecution> >::reset (this=0x555556267590 = {...}, __p=0x0) at /usr/include/c++/13/bits/unique_ptr.h:509
#12 0x00007ffff7d174ca in albert::detail::Query::~Query (this=0x555555a11cc0, __in_chrg=<optimized out>) at /home/devdave/projects/albert/src/query/query.cpp:61
#13 0x00007ffff7d17506 in albert::detail::Query::~Query (this=0x555555a11cc0, __in_chrg=<optimized out>) at /home/devdave/projects/albert/src/query/query.cpp:62

If I go up the stack to frame #12 the content of albert::detail::Query is

this = {albert::detail::Query *const} 0x555555fc4280 
 albert::QueryContext = {albert::QueryContext} 
 d = {std::unique_ptr<albert::detail::Query::Private>} 
  get() = {albert::detail::Query::Private *} 0x55555639e2d0 
   usage_scoring = {albert::UsageScoring} 
   valid = {std::atomic_bool} false
   handler = {albert::QueryHandler &} 
   trigger = {QString} "docs "
   string = {QString} ""
   matches = {albert::QueryResults} 
   fallbacks = {albert::QueryResults} 
   execution = {std::unique_ptr<albert::QueryExecution>} 

is that expected behavior for the string part of the query to be empty?

also

(gdb) info threads
  Id   Target Id                                           Frame 
* 1    Thread 0x7ffff25c3640 (LWP 15453) "albert"          0x00007ffff7498d71 in __futex_abstimed_wait_common64 (private=1076232192, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5555562675f0) at ./nptl/futex-internal.c:57
  2    Thread 0x7ffff17ff6c0 (LWP 15457) "QXcbEventQueue"  0x00007ffff751b4fd in __GI___poll (fds=0x7ffff17fe768, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  3    Thread 0x7fffebe1d6c0 (LWP 15458) "pool-spawner"    syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4    Thread 0x7fffe35ff6c0 (LWP 15459) "gmain"           0x00007ffff751b4fd in __GI___poll (fds=0x555555644500, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  5    Thread 0x7fffeb61c6c0 (LWP 15460) "gdbus"           0x00007ffff751b4fd in __GI___poll (fds=0x7fffd4000b90, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  6    Thread 0x7fffead996c0 (LWP 15461) "QDBusConnection" 0x00007ffff751b4fd in __GI___poll (fds=0x7fffd8016130, nfds=5, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  13   Thread 0x7fffe17fd6c0 (LWP 15480) "QNetworkAccessM" 0x00007ffff751b4fd in __GI___poll (fds=0x7fffb4001510, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  26   Thread 0x7fff91ffb6c0 (LWP 15518) "Thread (pooled)" 0x00007ffff751baca in __GI___libc_read (nbytes=4096, buf=0x7fff7c000b70, fd=39) at ../sysdeps/unix/sysv/linux/read.c:26

I am thinking the thread the GUI is stuck on is already dead or at least cleaned itself up and is waiting for the next task.

[ManuelSchneid3r]

Interesting how the amount of deadlocks exploded in this version. I fixed two of them today, but this looks like another one 🤦‍♂️

[devdave]

I hate threading race condition bugs. Looking into a hypothesis that the concurrent finishes even before its added to the future watcher, technically it should fire finished the finished signal, but it would make sense given everything in the thread pool is on standby or already culled.

[Sandalas]

I also encountered (not so) random freezes. For me, it always happen, after using a python plugin.
I do not have to execute the python plugin the search alone is enough to freeze albert after closing the launcher.

Example

Working:
Open the launcher - Use one of the build in features - Open the launcher again

Freeze:
Open the launcher - Use "wiki test" for the python wikipedia plugin - Press enter - Wikipedia opens - Launcher won't open again and settings or quit are not working

Freeze:
Open the launcher - Use "kill test" for the python kill plugin - Delete string - Use one of the build in features - Launcher won't open again and settings or quit are not working

HTH

[ManuelSchneid3r]

Which OS and Version?

[tomsquest]

Hi @ManuelSchneid3r ,

I can also report a "random freeze" issue since a couple of version back.
Maybe that could help (I am unsure, so I prefer to report and you discard my comment, that not giving the info).

Whenever I paste an emoji (albert > emoji selection > press `Enter), Albert freezes. It's 100% reproducible on my system.

Ubuntu 24.04 LTS, latest Albert (I don't have the exact version here, but the one from a couple day ago, and I know you do release a lot trying to squash that bug).

[ManuelSchneid3r]

Please test if 3.0.10 fixes this.

[ManuelSchneid3r]

I could not reproduce on noble manjaro and macos. Let me know

[tomsquest]

@ManuelSchneid3r Working perfectly fine with latest version (paste from emoji plugin was freezing).

[iluhaar]

Confirming that my freeze after using the clipboard issue was fixed in v34.0.10. Thank you for a quick fix 👍🏻