[cairo] Re : Re : Re : multithreaded bug in cairo on call to cairo stroke?

[Philippe Leroux]

oops, had not seen attachment 

just tried it
it works

i also tried the version of pixmap with safe simpleops (without patch you sent: 
with orginal libcairo)
and it works

the patch seems to cut short some cairo optimization or something? 
just to note, that in my case, there seems to be no difference in speed from one 
solution or the other

by source, you mean cairo_surface?
because each of my "goroutine" as they call it,  call to lockOSthreads,( to 
force them to be on an os thread and not multiplexed on different threads)
creates its own cairo_surface (cairo_image_surface_create) then the context 
(cairo_create(the surface)), draws, save image, clears, draw again save.....

did i miss something here?
am i doing something wrong?
do you think that the go language may not be correctly locking the goroutine on 
an os thread?

many thanks for your kind help! i much appreciate the time spared by having a 
real multithreaded simulator (that does makes that corei7 roar)
i definitely owe you a beer !
if ever you drop by bolzano Italy!

sincerely

Philippe


----- Message initial ----
De : Andrea Canciani <ranma42 at gmail.com>
À : Philippe Leroux <lerouxp at yahoo.ca>
Cc : cairo <cairo at cairographics.org>
Envoyé le : Mer 15 décembre 2010, 11h 32min 33s
Objet : Re: Re : [cairo] Re : multithreaded bug in cairo on call to cairo 
stroke?

On Wed, Dec 15, 2010 at 11:00 AM, Philippe Leroux <lerouxp at yahoo.ca> wrote:
>
>
> thanks for your answer
> i could give it a try to that pixman threadsafe lib
> however i'm not sure that this is the problem
>
> each of my drawing threads uses it's own surface to draw to,
> they create a surface, a context, draws to them and saves the images
> get a new data set clears the surface, draw again, save another image and so 
on
> each thread uses independent data sets.
> error always happen when two threads call to cairo stroke or fill
>
> so unless i am missing something here, there is a bug somewhere
> maybe something very tricky

You are probably using the same source in multiple threads, because cairo
tries to be clever and caches solid colors.
Can you please test the attached patch to check if it works around your problem?
It would be a strong hint that you're having problems with atomic refcounting.

> it never bugs in exactly the same way
> (corruption double free, corrupted double-linked list sigabrt segfault)
> sometimes from libpixman, sometimes from libGL, libxcb...
>
> what do you think?
> i've tried looking at cairo-trace... it's a big log file. i'm not sure how i 
>can
> find some insight in it

If the attached patch does not work around your problem, could you provide
a backtrace with debug symbols?

Andrea