Comment 6 for bug 1199571

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...