[cairo] BUG: Cairo reports CAIRO_STATUS_SUCCESS even if writing to disk failed (SVG and PS backend)

[Uli Schlachter]

Am 24.07.21 um 14:08 schrieb Knut Petersen:
[...]
> PDF backend:  Context status reports a write error after the very first
> show_page. Perfect. File size of the pdf file on a non-full file system:
> 102906 Bytes. But your test fails ... could this depend on the amount of
> data to be written?

Yup, possible. I guess as long as libc buffers the PDF, the error would
be only caught at the place my patch fixes.

However, I didn't look at the code and this is just a guess.

> PS backend: No error for any context status, but the surface status
> after cairo_finish correctly reports a write error. File size of the ps
> file on a non-full file system: 516973 Bytes. Your test also reports an
> error. Fine.

I guess that PS only writes anything when finishing the surface? Dunno,
again just a guess.

> SVG backend: No error for any context status, no error for any surface
> status. Expected file sizes for the three output files on a non-full
> file system: 265707 Bytes, 22609 Bytes, 45018 Bytes. Your test program
> does not contain a svg test, I added such a test. That test also
> incorrectly reports success on a full file system. So the svg backend is
> definitely still broken.

Yay, this one is fun. The error is correctly identified with debian
testing's libcairo, but not with git master. Which means this can be
"git bisect"ed. The result is:

c5b24a3e12815fce328997a9b5825d732329cc4b is the first bad commit
commit c5b24a3e12815fce328997a9b5825d732329cc4b
Author: Anton Danilkin <afdw at yandex.ru>
Date:   Sun Apr 11 19:48:50 2021 +0200

    Start implementing correct paints in transformed recording patterns


I opened [0] for fixing this. This is almost identical to what cairo-pdf
did wrong. The existing test even already caught this error, but this
failure was ignored in CI.

[0]: https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/212

[...]
> Attached the extended test program. It reports:

Thanks for that!

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