Seg fault on close about xfiles HOT 4 CLOSED

I could not reproduce that. Can you run xfiles on gdb and get the backtrace to comment it here?

from xfiles.

(gdb) run
Starting program: /home/redlolz/src/xfiles/xfiles
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f44b70 in ?? () from /usr/lib/libfontconfig.so.1
(gdb) bt
#0  0x00007ffff7f44b70 in ?? () from /usr/lib/libfontconfig.so.1
#1  0x00007ffff7f0c490 in ?? () from /usr/lib/libXft.so.2
#2  0x00007ffff7f0c63c in ?? () from /usr/lib/libXft.so.2
#3  0x00007ffff7f0c72c in ?? () from /usr/lib/libXft.so.2
#4  0x00007ffff7de5de2 in XCloseDisplay () from /usr/lib/libX11.so.6
#5  0x0000555555577b49 in widget_free (widget=0x5555555ab510) at widget.c:3228
#6  0x000055555556ed1d in main (argc=0, argv=0x7fffffffdff0) at xfiles.c:1047

Versions of those libraries:
fontconfig: 2:2.14.2-1
libxft: 2.3.8-1
libx11: 1.8.5-2

from xfiles.

I could finally reproduce this bug! And should (hopefully) be fixed now.

Quoting the commit message:

A FontConfig pattern is an object containing name-value pairs describing Xft fonts (family, style, slant, etc). A partially filled pattern (with some pairs left undefined) is called "search pattern" and can match more than one Xft font. A fully filled pattern is called "match pattern" and matches exactly one font.

XftFontOpenPattern(3) opens a Xft font from match pattern. Until now, I was freeing the match pattern with FcPatternDestroy(3) after getting the resulting Xft font (seems fair, I don't need the match pattern anumore). However, the match pattern should outlive its Xft font.

The match pattern is not really destroyed. X11 decrements the reference to objects, so the match pattern could still be accessed by the Xft font referring to it. Thus, calling FcPatternDestroy(3) on the pattern right after getting the Xft font wasn't a problem... until closing the program and XCloseDisplay(3) destroys the remaining X11 resources. I don't know really what happens, I think the pattern is freed twice or its reference counter gets messed up by both our call to FcPatternDestroy(3) on itself and the call to XftFontClose(3) on its Xft font. Anyway, in the end the program segfaults.

That bug only happens when using Xft fonts obviously. I first could not reproduce it because I use an old XLFD bitmap font. Also, this bug does not occurs on OpenBSD; I could only reproduce it on GNU/Linux... I have no idea why.

I fixed it by, for each font, saving the Xft font and its match pattern. Both are destroyed when freeing the font.

from xfiles.

Can confirm, no more seg faults.
Thank you!

from xfiles.