Bug 107380 - fonts can be munged across processes, missing global locks, and errors in XCloseDisplay with unrefd fonts
Summary: fonts can be munged across processes, missing global locks, and errors in XC...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xft (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-25 21:56 UTC by guy goode
Modified: 2018-08-10 20:15 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
font unit test, ppms: ref.ppm, bug.ppm (20.85 KB, application/x-compressed-tar)
2018-07-25 21:56 UTC, guy goode
no flags Details

Description guy goode 2018-07-25 21:56:21 UTC
Created attachment 140815 [details]
font unit test, ppms: ref.ppm, bug.ppm

I have been working around various errors in Xft freetype and fontconfig for some time, with some success... but now I need help.  The big issue is that even if I add workarounds in my code, other code can apparently munge font data that is then shared by the server.  This creates visible errors in rendered glyphs.
see attachment test.tgz and inspect ppms/ref.ppm, ppms/bug.ppm

First, the easy stuff.

1) The global data in libXft should be locked.  It definitely can crash the program.  The most frequent errors are segvs and infinite loops because the _XftDisplayInfo list is global, and is modified without locks in _XftDisplayInfoGet for a MRU update when info is accessed. There is more global data than this which should be locked.
nm -a src/.libs/libXft.a | grep " [bBdDcC] ":
0000000000000000 b debug.11726
0000000000000004 b initialized.11725
0000000000000008 C _XftDisplayInfo
0000000000000000 b _XftFtFiles
0000000000000008 C _XftFTlibrary
0000000000000014 b XftAllocCount
0000000000000010 b XftAllocMem
0000000000000004 b XftAllocNotify
0000000000000018 b _XftConfigInitialized
000000000000000c b XftFreeCount
0000000000000008 b XftFreeMem
0000000000000000 b XftFreeNotify
0000000000000000 d XftInUse
0000000000000000 b _XftNameInitialized
0000000000000000 d XftXlfdSlants
0000000000000040 d XftXlfdWeights
Most of this needs a lock.

2) Closing a display with unrefd fonts always creates an XError failure.
This is because there are events generated by _XftCloseDisplay which attempt to use the transport during XSync(display,1).  This can be avoided by closing the fonts with maxunreffonts=0, so that the cleanup is done while the transport is usable.
example:
 FcPattern *defaults = FcPatternCreate();
 FcPatternAddInteger(defaults, "maxunreffonts", 0);
 XftDefaultSet(display, defaults);
 xftFontClose (display, xft_font);
 ...
 XCloseDisplay(display);

Now, the one that is too hard for me to find or workaround.

3) The glyph data can be corrupted by another process. I have written a unit test program (attached) which uses techniques similar to the application code which I use.  If I run it by itself, it seems to work.  If I run multiple processes of it (2 or 3 usually), it works.  If I run even one copy, and bring up ooffice on a big document, and scroll it around (to force a bunch of glyph operations), within a minute or so the bug trap is triggered.

I rate these bugs as serious.

All of them can be produced with the attached unit test.
[root@xray tmp]# ./a.out 1         # unlocked globals
Segmentation fault (core dumped)
[root@xray tmp]# ./a.out 2         # unrefd fonts
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  160 ()
  Minor opcode of failed request:  0
  Serial number of failed request:  83
  Current serial number in output stream:  125
[root@xray tmp]# ./a.out           # munged glyph
BUG 0x7f81271ce700

This should probably be broken into 3 bugs,
but this is a good starting point.

If this is not the place to submit this bug report, please let me know.
Comment 1 guy goode 2018-07-25 22:28:05 UTC
Looks like the global data lock bug has been here for a while.
see bug 15994
https://bugs.freedesktop.org/show_bug.cgi?id=15994
Comment 2 GitLab Migration User 2018-08-10 20:15:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxft/issues/4.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.