cairo_scaled_font_destroy may destroy fonts that have been created on a different backend. I am hitting a deadlock in one of my programs because of this. What happens is that GDK is doing some X calls (eg. XSync) while a second thread is rendering a PDF. The PDF rendering causes cairo_scaled_font_destroy, which in turn calls XRenderFreeGlyphSet.

From IRC:
< psychon> ickle: ^ (I guess that cairo is supposed to only call into Xlib from threads that use cairo-xlib, so this XFreeGlyphSet is wrong)
< ickle> restore the taskqueue


This is the backtrace of the X call that should not happen:
(gdb) bt
#0  _XGetRequest (dpy=0xdac8e0, type=19 '\023', len=8) at ../../src/XlibInt.c:1967
#1  0x00007fffeffd3f00 in XRenderFreeGlyphSet () from /usr/lib/x86_64-linux-gnu/libXrender.so.1
#2  0x00007ffff23094b6 in _cairo_xlib_font_fini (abstract_private=0x1316820, font=<optimized out>)
    at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo-xlib-render-compositor.c:718
#3  0x00007ffff22daae1 in _cairo_scaled_font_fini_internal (scaled_font=0x1318a80) at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo-scaled-font.c:864
#4  0x00007ffff22db13d in cairo_scaled_font_destroy (scaled_font=<optimized out>) at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo-scaled-font.c:1337
#5  INT_cairo_scaled_font_destroy (scaled_font=<optimized out>) at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo-scaled-font.c:1273
#6  0x00007ffff22a8d79 in _cairo_gstate_unset_scaled_font (gstate=<error reading variable: Unhandled dwarf expression opcode 0xfa>, 
    gstate=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo-gstate.c:1632
#7  0x00007ffff22ac897 in _cairo_gstate_set_font_face (gstate=0x1347630, font_face=0xde1ac0) at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo-gstate.c:1873
#8  0x00007ffff229f565 in cairo_set_font_face (cr=0x11bd360, font_face=<optimized out>) at /var/tmp/cairo-1.12.3~fsetec.2/src/cairo.c:2790
#9  0x00007fffe52ca39c in CairoOutputDev::updateFont(GfxState*) () from /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
#10 0x00007fffe4f4883d in Gfx::opShowSpaceText(Object*, int) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#11 0x00007fffe4f411b4 in Gfx::go(bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#12 0x00007fffe4f41620 in Gfx::display(Object*, bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#13 0x00007fffe4f81d94 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#14 0x00007fffe52c0f69 in ?? () from /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
#15 0x00007ffff4eff7bc in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.5

----

For people interested (not really that important), this is how it hangs later on. XCB is waiting for a too high sequence number, because the above call was counted internally, but not send to the X server.
(gdb) bt
#0  0x00007ffff6e46e73 in *__GI___poll (fds=<optimized out>, fds@entry=0x7fffffffcc90, nfds=<optimized out>, nfds@entry=1, timeout=timeout@entry=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007ffff7bc8212 in _xcb_conn_wait (c=c@entry=0xdb0a10, cond=cond@entry=0x7fffffffcd00, vector=vector@entry=0x0, count=count@entry=0x0)
    at ../../src/xcb_conn.c:400
#2  0x00007ffff7bc9747 in wait_for_reply (c=c@entry=0xdb0a10, request=21351, e=e@entry=0x7fffffffcdc8) at ../../src/xcb_in.c:390
#3  0x00007ffff7bc996b in xcb_wait_for_reply (c=0xdb0a10, request=21351, e=0x7fffffffcdc8) at ../../src/xcb_in.c:420
#4  0x00007ffff2fdf32d in _XReply (dpy=0xdac8e0, rep=0x7fffffffce20, extra=6, discard=0) at ../../src/xcb_io.c:601
#5  0x00007ffff2d9701a in XIQueryPointer () from /usr/lib/x86_64-linux-gnu/libXi.so.6