Huge multi-threading violations in freetype

StacktraceTop:
 af_latin_hints_compute_edges (dim=<optimized out>, hints=<optimized out>) at /build/buildd/freetype-2.4.12/freetype-2.4.12/src/autofit/aflatin.c:1271
 af_latin_hints_detect_features (hints=<optimized out>, dim=<optimized out>) at /build/buildd/freetype-2.4.12/freetype-2.4.12/src/autofit/aflatin.c:1411
 af_latin_hints_apply (hints=0x1953d58, outline=0x1953ee0, metrics=0x7ff37002c950) at /build/buildd/freetype-2.4.12/freetype-2.4.12/src/autofit/aflatin.c:2381
 af_loader_load_g (loader=loader@entry=0x1953d40, scaler=scaler@entry=0x7ff383feb790, glyph_index=glyph_index@entry=33, load_flags=load_flags@entry=68097, depth=depth@entry=0) at /build/buildd/freetype-2.4.12/freetype-2.4.12/src/autofit/afloader.c:184
 af_loader_load_glyph (load_flags=68097, gindex=<optimized out>, face=<optimized out>, module=<optimized out>) at /build/buildd/freetype-2.4.12/freetype-2.4.12/src/autofit/afloader.c:553

e.u.c report on https://errors.ubuntu.com/problem/62a5e02a5ec4ed62cd98c21d2ff80a5cdf6aec47

I looked at my coredump on trusty (it crashed for me twice already!) with gdb and I see evidence that this crash might be due to multithreading issues. The reason is that when inspecting memory at %rdx (edge) and I see that a pointer at %rdx+0x48 (edge->first) doesn't match with a pointer in %rcx (edge->first taken at the start of the loop). Besides, freetype code can never produce %rax == 0 at the crash location, this would only happen if af_latin_hints_compute_edges is called concurrently on the same hints structure, which causes pointers to change for segments that are processed in another thread. Best of luck, ThreadStackTrace.txt shows exactly that, two threads are in af_latin_hints_compute_edges with same parameters!

Now the real question is which application or library is actually violating thread-safety here...

I looked at the implementation of cairo-ft-font.c and it seems that there are huge multi-threading violations in cairo. The reason is that FreeType API documentation clearly states:

In multi-threaded applications, make sure that the same FT_Library object or any of its children doesn't get accessed in parallel.

Cairo initializes FT_Library for its font map and there's a lock for that, however it's only used for font map manipulations, the actual FT_ library calls are completely unprotected with that lock, although they should be! What adds to the injury is that cairo-ft-font.c even has this comment on one of its functions:

You must be careful when using this function in a library or in a
threaded application, because freetype's design makes it unsafe to
call freetype functions simultaneously from multiple threads, (even
if using distinct FT_Face objects)

Too bad they don't follow their own advice, and no wonder compiz is crashing like that. Can somebody contact upstream about this issue and make them aware of it?

Status changed to 'Confirmed' because the bug affects multiple users.

Brilliant work, Alexey.

Status changed to 'Confirmed' because the bug affects multiple users.

This crash happened with libfreetype6 2.4.12-0ubuntu1 installed. Is it still reproducible with 2.5.2-1ubuntu2, the version in Ubuntu 14.04?

actually, based on the previous comment it looks lke it almost certainly would still occur with new freetype since these interfaces are not thread-safe; seems that this need to be fixed in cairo (or in compiz applying its own mutexes).

Steve, the latest duplicate shows 2.5.2-1ubuntu2:

https://bugs.launchpad.net/bugs/1304763

Is it possible to get some input from cairo maintainers?

> Is it possible to get some input from cairo maintainers?

There is not really an "Ubuntu cairo maintainer", the bug should be report to upstream on https://bugs.freedesktop.org/enter_bug.cgi?product=cairo

It severely affects packages beyond the one that causes the flaw.

Yes, thank you.

Will this fix be released for 14.04, or do I have to wait for 15.04?

Tarjei: as always it happens with important bugs, they are first released to the development version and after that it has been verified there, it will be backported to trusty as well through an SRU (code in place for that is already there).

This bug was fixed in the package freetype - 2.5.2-2ubuntu2

---------------
freetype (2.5.2-2ubuntu2) vivid; urgency=medium

  * Added patchset to fix multithread violations, LP: #1199571
    - debian/patches-freetype/multi-thread-violations.patch
 -- Marco Trevisan (Trevino) <email address hidden> Fri, 23 Jan 2015 03:23:18 +0100

This bug report is missing Stable Release Update information as discussed at http://wiki.ubuntu.com/StableReleaseUpdates. A test case isn't strictly necessary for this bug report as there is at least one crash report at the Ubuntu Error Tracker we can use to make sure the version of the package being SRU'ed isn't appearing there.

Hello Brad, or anyone else affected,

Accepted freetype into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/freetype/2.5.2-1ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Everything work as expected with new freetype 2.5.2-1ubuntu2.3

This is what was happening with freetype 2.5.2-1ubuntu2.2
time while ./ftthread /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf 40 10000 150 4; do echo -n '.'; done
FT_Load_Glyph failed: FT_Err_Invalid_Reference: invalid reference.
Segmentation fault (core dump created)

real 0m0.376s

This is instead what I'm getting with 2.5.2-1ubuntu2.3:

time while ./ftthread /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf 40 10000 150 4; do echo -n '.'; done
...........................................

real 32m0.545s

This bug was fixed in the package freetype - 2.5.2-1ubuntu2.3

---------------
freetype (2.5.2-1ubuntu2.3) trusty; urgency=medium

  * Added patchset to fix multithread violations, LP: #1199571
    - debian/patches-freetype/multi-thread-violations.patch
 -- Marco Trevisan (Trevino) <email address hidden> Fri, 23 Jan 2015 03:38:04 +0100

The verification of the Stable Release Update for freetype has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.