Hi,
I can reproduce this bug on Ubuntu 26.04 with:
|evince 49~alpha-2ubuntu2.1 libgtk-4-1 4.22.4+ds-0ubuntu0.1
libglib2.0-0t64 2.88.0-1ubuntu0.1|
The hang is triggered reproducibly by moving the mouse pointer over an
internal PDF link, for example a LaTeX |\cite|hyperlink : evince hangs,
no pup-up is shown.
While hung, |top -H|shows that the Evince main thread consumes
essentially 100% of one CPU, while the worker threads are idle.
Stopping it in gdb gives this backtrace for the busy main thread:
|#0 rdtsc_ordered #1 __arch_get_hw_counter #2 vdso_get_timestamp #3
do_hres #4 __cvdso_clock_gettime_common #5 __cvdso_clock_gettime_data #6
__clock_gettime #7 g_get_monotonic_time_ns #8 g_get_monotonic_time #9
g_source_get_time #10 ... in libgtk-4.so.1 #11
g_main_context_prepare_unlocked #12 g_main_context_prepare_unlocked #13
g_main_context_iterate_unlocked #14 g_main_context_iteration #15
g_application_run #16 main|
This looks like a GTK/GLib main-loop source spinning continuously after
the link-preview popup is triggered.
BTW I also checked AppArmor because of related Evince/glycin issues: the
Evince profile includes the glycin abstraction, permits the bwrap
transition, and there are no AppArmor DENIED messages when reproducing
this hang. So this appears unrelated to the AppArmor/glycin problem that
some are experiencing, and matches the hover-link regression described
in this bug.
Best regards,
Andrea
