[cairo] Thread-safety and library versions

[Uli Schlachter]

Hi,

On 17.09.2013 14:16, Weeble wrote:
[...]
> More specifically, I'm running libcairo 1.12.14 and libfontconfig
> 2.10.2. When Mono repeatedly creates cairo drawing contexts, calls
> cairo_select_font_face, and destroys the drawing contexts; (with each
> context accessed only from a single thread, but more than one thread
> running at once;) sooner or later it crashes when
> _cairo_toy_font_face_destroy calls _cairo_hash_table_remove and raises
> an assertion, apparently because the key is missing from the hash
> table.

I was thinking "it can't be that simple" and produced the attached test program
which does exactly this. The result with current cairo from git:

a.out: cairo-hash.c:506: _cairo_hash_table_lookup_exact_key: Assertion
`!"reached"' failed.

Could someone with more clue about how things are supposed to work take a look
at this? Chris? Behdad?

> Could this crash be caused by having an old version of
> fontconfig? There's no obvious involvement of fontconfig in this stack
> trace, but if this combination of libraries is known to have
> thread-safety issues I wonder if it could be due to memory corruption.

Just my 5c, but I don't think that this is due to fontconfig either.

> (Much more rarely, it crashes in FcPatternDestroy, with an assertion
> about a double-free or memory corruption, so I do have reason to
> suspect fontconfig, although I am not certain these crashes have the
> same cause.)
[...]

Haven't seen such a crash yet.

Cheers,
Uli
-- 
<alanc> I think someone had a Xprint version of glxgears at one point,
    but benchmarking how many GL pages you can print per second
    was deemed too silly to merge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 732 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20130917/49a4db34/attachment.c>