| Summary: | Segfault on cairo_surface_destroy() | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Szuromi Gábor <kukkerman> |
| Component: | win32 backend | Assignee: | cairo-bugs mailing list <cairo-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 1.10.3 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
commit 86a89a8c1de88f279b306ac8e3461773895aa7a2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar 20 19:14:28 2012 +0000 win32: Check for damage before blitting During the surface flush, we reduce any pending damage and then blit. If no damage had been accrued then the damage->region would be NULL leading to a segfault. Patch suggested by Szuromi Gábor. Reported-by: Szuromi Gábor <kukkerman@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47605 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Destroying a win32 paint surface after we're done with painting cairo_surface_destroy() causes a segmentation fault. After further examination the source of the problem lies in _cairo_win32_display_surface_flush in /src/win32/cairo-win32-display-surface.c at line 520 (at least in commit f5b5fad66e9c545f332a5f5cf8bd86c7d77caa93): int n = cairo_region_num_rectangles (damage->region), i; The call will fail if damage->region is a NULL pointer, so it should be checked either in cairo_region_num_rectangles or before calling it. I've tried the former by replacing the else block with an if statement in line 519: } else if (damage->region != NULL) { After that cairo_surface_destroy() behaves as expected but I haven't tested it thoroughly, furthermore I'm not even sure that this is the right thing to do because I'm not familiar with the internals of cairo. The bug appears to be connected with the new compositor infrastructure presented in commit ae3319890eacd1c8282ca6df7b263ac74abb5f8d.