[cairo] Time for a release ?

[Heiko Lewin]

>>> Or am I misunderstanding
>>> you and you do not mean "admin work" as "keep GitLab running", but
>>> rather "make the test suite pass"?
>> Even with only testing image surfaces, the test-suite seems to deadlock:
>>
>> TESTING pthread-show-text
>> pthread-show-text.image.argb32 [0x1]:    FAIL
>> pthread-show-text.image.rgb24 [0x1]:    ^C
> Sorry, but that works fine here (commit 9a3ad1d from August 31). Running
> "CAIRO_TEST_TARGET=image /usr/bin/time ./cairo-test-suite
> pthread-show-text" finishes in 50 milliseconds.

Which (sadly) demonstrates the problem.
I have to admit, that I need build with "--enable-fc=no" and quite a few
tries calling the suite in a loop.
See the attached crash.txt - it is the first crash I got from this.


>> "Making it pass" I would remove all thread-shared data-objects from
>> cairo. No "holdovers" or caching of font-faces and stuff which could be
>> done on an application-layer.
> I always tried to stay away from the font stuff, so I cannot comment on
> that, but I *think* that is allowed to use the same font face from
> multiple threads, so just removing all caches would not solve all thread
> issues.
Parallel use of cairo_font_face_t and scaled font is not permitted at
least with freetype.
Freetype does not permit it either and cairo afaik has no locks around
the usages of freetype-structs.
No, the code I am speaking of is the "recycling" of scaled fonts in
cairo-scaled-font.c.
There is a global static LRU map of fonts that were used, there is the
MRU-font stored separately,
and much fiddling around with atomics in a try to transfer fonts from or
to those locations while
keeping their reference-count right.
I've yet seen two or three commits that try to fix that stuff but,
somehow, I still have doubts (besides the LRU holdovers is
much too large for my needs and cannot be configured programmatically:
256 LRU fonts can easily be a >100MB of data).
 From my point of view much of the problem resolves around the
ref-counting of the fonts. The implementation tries to keep around
fonts with refcount==0 and hence cannot rely on the auto-cleanup itself.
This leads to endless blocks of "was that the last reference?
Has someone referenced this font while I was busy? In which state am
I?"  ->  *BOOF*
My best advice: Separate the caching from the basic functionality.
Keeping a map of properly ref-counted objects is not that hard.


> [...]
>> [...] however I cannot remember the test-suite passing at
>> any time,
> Yup, I never saw the test suite passing either.

Which surely is a problem as then you don't know either if there is a
real problem.


>
> [...]
>> Might seem keen, but I'd wait on concrete reports from a test-release.
>> If there really is something broken, ppl will come and fix it or they
>> won't.
> [...]
>
> Well, there are some crash reports in GitLab. I vaguely remember one
> with a patch where the patch is just "let's make this array slightly
> larger, because that seems to make the crash go away". I do not really
> like that since it feels like it could just hide the real bug. How would
> you deal with that?
Honestly, I don't know. If it does not make sense then one of you knows
something the other does not.
That would take explanation, I guess. It is sad the source is poorly
documented but you either succeed to
show the array needs to be larger or you do not. Sounds like an idea:
Let him write sufficient documentation
to make your doubt go away. This can also serve as rubber-duck-debugging.


Regards,
Heiko
-------------- next part --------------
...

TESTING pthread-show-text
pthread-show-text.image.argb32 [0x1]:    FAIL
pthread-show-text.image.rgb24 [0x1]:    FAIL
pthread-show-text: FAIL (image)
0 Passed, 1 Failed [0 crashed, 0 expected], 0 Skipped
image (argb32): 1 failed - pthread-show-text
image (rgb24): 1 failed - pthread-show-text

Note: These failures may be due to external factors.
Please read test/README -- "Getting the elusive zero failures".

TESTING cairo-test-suite
Compiled against cairo 1.17.3, running on 1.17.3.
Compiled against pixman 0.40.0, running on 0.40.0.

TESTING pthread-show-text
pthread-show-text.image.argb32 [0x1]:    FAIL
pthread-show-text.image.rgb24 [0x1]:    FAIL
pthread-show-text: FAIL (image)
0 Passed, 1 Failed [0 crashed, 0 expected], 0 Skipped
image (argb32): 1 failed - pthread-show-text
image (rgb24): 1 failed - pthread-show-text

Note: These failures may be due to external factors.
Please read test/README -- "Getting the elusive zero failures".

TESTING cairo-test-suite
Compiled against cairo 1.17.3, running on 1.17.3.
Compiled against pixman 0.40.0, running on 0.40.0.

TESTING pthread-show-text
pthread-show-text.image.argb32 [0x1]:    FAIL
pthread-show-text.image.rgb24 [0x1]:    FAIL
pthread-show-text: FAIL (image)
0 Passed, 1 Failed [0 crashed, 0 expected], 0 Skipped
image (argb32): 1 failed - pthread-show-text
image (rgb24): 1 failed - pthread-show-text

Note: These failures may be due to external factors.
Please read test/README -- "Getting the elusive zero failures".

TESTING cairo-test-suite
Compiled against cairo 1.17.3, running on 1.17.3.
Compiled against pixman 0.40.0, running on 0.40.0.

TESTING pthread-show-text
pthread-show-text.image.argb32 [0x1]:    FAIL
pthread-show-text.image.rgb24 [0x1]:    FAIL
pthread-show-text: FAIL (image)
0 Passed, 1 Failed [0 crashed, 0 expected], 0 Skipped
image (argb32): 1 failed - pthread-show-text
image (rgb24): 1 failed - pthread-show-text

Note: These failures may be due to external factors.
Please read test/README -- "Getting the elusive zero failures".

TESTING cairo-test-suite
Compiled against cairo 1.17.3, running on 1.17.3.
Compiled against pixman 0.40.0, running on 0.40.0.

TESTING pthread-show-text
pthread-show-text.image.argb32 [0x1]:    lt-cairo-test-suite: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
pthread-show-text.image.argb32 [0x1]:    !!!CRASHED!!!
*** stack smashing detected ***: terminated
pthread-show-text.image.rgb24 [0x1]:    ^C