[cairo] Memory (?) problems with master

[Chris Wilson]

On Fri, 2009-08-14 at 17:21 -0500, Damian Frank wrote:
> On Fri, Aug 14, 2009 at 4:31 PM, Chris Wilson
> <chris at chris-wilson.co.uk> wrote:
>         And if you can produce a test case, this would seem to be an
>         important
>         omission from the current test suite.
> 
> Unfortunately, it's a pretty complex test case.  What's the right way
> to capture output right now (cairo-script?) and how well does it work?

Difficult on win32, otherwise we could just use cairo-trace. The
technique that I use is to use a meta-surface duplicate of the active
surface and then replay that to a script-surface in order to generate a
failing trace. Running in 'flight-recorder mode', whereby we keep a
ring-buffer of the last n contexts and dump those on error (which
obviously needs to be robust in the face of memory errors). An
interesting challenge.

>    If I can use something to produce a good, simple C test case that
> would help a lot.  Without that, doing a bisect would take a very long
> time for me.

We have tools to replay traces. Automatically generating minimal traces
and running git bisect is a wishlist feature, that is getting closer to
reality with every regression report. (In other words, the tools keep
getting refined in order to find bugs and eventually they won't need me
any more.) As part of that process the tool should generate (and
commit!) a C test case (but that is still entirely manual,
autogeneration of the minimal trace is the first priority). And just
recently the idea was floated that we can extend regression hunting
quite simply to cover performance as well - including suggestions on how
we can classify applications and autogenerate microbenchmarks for
fine-grained regression tracking. [I digress, apologies, but I find it a
fascinating topic.]

> The segfaults are rare, but I see them on windows, generally after a
> few frames, inside a cairo_fill with a simple rectangular path
> intended to clear the surface (a DIB surface).  Pursuing the linux
> problems is probably more fruitful, given how painful and slow it is
> to actually get a windows build.

Unfortunately the linux builds are more extensively tested. We have
valgrind coupled into our test suite and so we can spot errors in the
linux backends more easily. I do not know how we can improve win32
testing (aside from tinderboxes) and would appreciate suggestions.
-ickle