Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

swaylock hangs on acquiring fontconfig lock, preventing the session from being unlocked #385

Open
danielmussell opened this issue Nov 12, 2024 · 2 comments

Comments

@danielmussell
Copy link

swaylock 1.8.0/fontconfig 2.15.0 on Fedora 41.

I have this intermittent issue where after entering my password, swaylock hangs and cannot unlock the session. When this happens, I need to switch to another VT and kill the session, which is inconvenient to say the least. A backtrace from gdb gives

#0  futex_wait (futex_word=0x7f2d600a2bb0, expected=2, private=0) at ../sysdeps/nptl/futex-internal.h:146
#1  __GI___lll_lock_wait (futex=futex@entry=0x7f2d600a2bb0, private=0) at lowlevellock.c:49
#2  0x00007f2d68911d81 in lll_mutex_lock_optimized (mutex=0x7f2d600a2bb0) at pthread_mutex_lock.c:48
#3  ___pthread_mutex_lock (mutex=0x7f2d600a2bb0) at pthread_mutex_lock.c:93
#4  0x00007f2d6870e88f in FcMutexLock (m=<optimized out>) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fcmutex.h:122
#5  0x00007f2d6870ff65 in FcCacheFindByAddr (object=0x7f2d67aba1c0) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fccache.c:657
#6  FcCacheObjectReference (object=0x7f2d67aba1c0) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fccache.c:747
#7  IA__FcCharSetCopy (src=0x7f2d67aba1c0) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fccharset.c:369
#8  IA__FcCharSetCopy (src=0x7f2d67aba1c0) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fccharset.c:362
#9  0x00007f2d68726cb8 in IA__FcValueSave (v=...) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fcpat.c:113
#10 0x00007f2d6872fd1f in FcFontSetMatchInternal (sets=sets@entry=0x7ffe9cfd7140, nsets=<optimized out>, p=p@entry=0x55c12e34f430, result=result@entry=0x7ffe9cfd71a4) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fcmatch.c:964
#11 0x00007f2d68731b97 in IA__FcFontMatch (config=0x7f2d60000b70, config@entry=0x0, p=p@entry=0x55c12e34f430, result=result@entry=0x7ffe9cfd71a4) at /usr/src/debug/fontconfig-2.15.0-8.fc41.x86_64/src/fcmatch.c:1084
#12 0x00007f2d68c2c8fd in _cairo_ft_resolve_pattern (pattern=0x55c12e34f430, font_matrix=<optimized out>, ctm=<optimized out>, font_options=0x7ffe9cfd7560) at ../src/cairo-ft-font.c:4420
#13 _cairo_ft_font_face_get_implementation (abstract_face=0x55c12e34b090, font_matrix=<optimized out>, ctm=<optimized out>, options=0x7ffe9cfd7560) at ../src/cairo-ft-font.c:4087
#14 0x00007f2d68be8297 in cairo_scaled_font_create (font_face=0x55c12e3591b0, font_matrix=0x55c12e3a2710, ctm=0x7ffe9cfd7530, options=0x7ffe9cfd7560) at ../src/cairo-scaled-font.c:1174
#15 0x00007f2d68bb7b08 in _cairo_gstate_ensure_scaled_font (gstate=0x55c12e3a2690) at ../src/cairo-gstate.c:1918
#16 _cairo_gstate_ensure_scaled_font (gstate=gstate@entry=0x55c12e3a2690) at ../src/cairo-gstate.c:1897
#17 0x00007f2d68bb7bd9 in _cairo_gstate_get_scaled_font (gstate=0x55c12e3a2690, scaled_font=<synthetic pointer>) at ../src/cairo-gstate.c:1790
#18 _cairo_default_context_get_scaled_font (abstract_cr=<optimized out>) at ../src/cairo-default-context.c:1325
#19 0x00007f2d68c0d422 in cairo_text_extents (cr=0x55c12e3a2660, utf8=utf8@entry=0x55c113bd0066 "Verifying", extents=extents@entry=0x7ffe9cfd76e0) at ../src/cairo.c:3414
#20 0x000055c113bcbe72 in render_frame (surface=surface@entry=0x55c12e3f6c80) at ../render.c:169
#21 0x000055c113bcca6b in surface_frame_handle_done (callback=<optimized out>, time=<optimized out>, data=0x55c12e3f6c80) at ../main.c:189
#22 surface_frame_handle_done (data=0x55c12e3f6c80, callback=<optimized out>, time=<optimized out>) at ../main.c:176
#23 0x00007f2d68022056 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#24 0x00007f2d6801d74d in ffi_call_int (cif=cif@entry=0x7ffe9cfd7940, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673
#25 0x00007f2d6802064e in ffi_call (cif=cif@entry=0x7ffe9cfd7940, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7ffe9cfd7a10) at ../src/x86/ffi64.c:710
#26 0x00007f2d68aa910e in wl_closure_invoke (closure=closure@entry=0x55c12e40aa60, target=<optimized out>, target@entry=0x55c12e431460, opcode=opcode@entry=0, data=<optimized out>, flags=1) at ../src/connection.c:1228
#27 0x00007f2d68aa9979 in dispatch_event (display=display@entry=0x55c12e3025f0, queue=queue@entry=0x55c12e3026e8) at ../src/wayland-client.c:1670
#28 0x00007f2d68aa9d73 in dispatch_queue (display=0x55c12e3025f0, queue=0x55c12e3026e8) at ../src/wayland-client.c:1816
#29 wl_display_dispatch_queue_pending (display=0x55c12e3025f0, queue=0x55c12e3026e8) at ../src/wayland-client.c:2058
#30 0x00007f2d68aab964 in wl_display_dispatch_queue (display=<optimized out>, queue=<optimized out>) at ../src/wayland-client.c:2034
#31 0x00007f2d68aab980 in wl_display_dispatch (display=<optimized out>) at ../src/wayland-client.c:2101
#32 0x000055c113bca034 in display_in (fd=<optimized out>, mask=<optimized out>, data=<optimized out>) at ../main.c:1070
#33 0x000055c113bc6ca1 in loop_poll (loop=0x55c12e3bc590) at ../loop.c:100
#34 main (argc=<optimized out>, argv=<optimized out>) at ../main.c:1292

No other software using cairo/fontconfig is affected, just swaylock, which is why I'm reporting it here. fontconfig#318 is likely related.

@kennylevinsen
Copy link
Member

swaylock doesn't directly interact with fontconfig - that's all handled inside cairo, and the lock for the cache is entirely internal to fontconfig, released by fontconfig's own cache functions on return.

The possible ways this could happen:

  1. A prior call to fontconfig went through a path where fontconfig failed to unlock the mutex, deadlocking all future calls
  2. A thread has been spawned for some reason, and made a call to fontconfig that ended up in an infinite loop under lock. Check with info threads.
  3. A memory corruption has occurred and the mutex was not, in fact, locked.

I see at least one path where fontconfig fails to unlock the cache lock: If allocation fails in FcCacheInsert. But that wouldn't normally happen.

@kennylevinsen
Copy link
Member

While I have no idea if that's your issue, MR for the missing cache unlock: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/341/diffs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants