<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Assertion failure in cairo under windows when using GIMP's new canvas rotation" href="https://bugs.freedesktop.org/show_bug.cgi?id=63787#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Assertion failure in cairo under windows when using GIMP's new canvas rotation" href="https://bugs.freedesktop.org/show_bug.cgi?id=63787">bug 63787</a> from <a class="email" href="mailto:psychon@znc.in" title="Uli Schlachter <psychon@znc.in>"> Uli Schlachter</a> <pre>Someone should paint a picture about this, the reference magic makes my head dizzy: At the cairo_restore() at the end of gimp_display_shell_render(), the current source of the gc is a surface pattern. In the rotated case, this pattern holds the only reference to the surface "xfer" which is a similar image to cairo_get_target(cr) (a win32 surface). Behind the covers, this image surface has a reference to a win32_display_surface (its parent). Now when the pattern is destroyed, the reference count to the similar image drops to zero (This seems correct, although the behind-the-scenes reference loop with the win32_display_surface still confuses me). While finishing this image surface, it drops the reference to its parent. Thus, now the win32_display_surface gets finished, too. In _cairo_win32_display_surface_finish(), this one now tries to get rid of the similar image again, although this one is already being finished some stack frames above. And *boom*, assert() notices that something went foobar. Whoever maintains cairo-win32 can come up with a good solution. Since these reference loops make my head hurt, I can only suggest to make _cairo_image_surface_finish() set ->parent to NULL before destroying its parent and then in _cairo_win32_display_surface_finish() check if the image surface's parent is still set before destroying the image. However, this hack smells quite fishy to me.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>