[PATCH 1/2] xwayland: Don't (double) destroy RANDR resources in CloseScreen

walter harms wharms at bfs.de
Wed Aug 5 00:13:49 PDT 2015



Am 04.08.2015 19:17, schrieb Adam Jackson:
> By the time we get here we've already been through FreeAllResources,
> which has already torn down the RANDR objects, so on the second
> regeneration you get:
> 
>     Invalid read of size 4
>        at 0x51C6F0: RRCrtcDestroy (rrcrtc.c:659)
>        by 0x4285F5: xwl_output_destroy (xwayland-output.c:191)
>        by 0x426464: xwl_close_screen (xwayland.c:112)
>        by 0x4B7F77: CursorCloseScreen (cursor.c:187)
>        by 0x536013: AnimCurCloseScreen (animcur.c:106)
>        by 0x539841: present_close_screen (present_screen.c:64)
>        by 0x43E496: dix_main (main.c:351)
>        by 0x30D70206FF: (below main) (libc-start.c:289)
>      Address 0x4cc6640 is 0 bytes inside a block of size 728 free'd
>        at 0x4A07D6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>        by 0x51BCCF: RRCrtcDestroyResource (rrcrtc.c:689)
>        by 0x45CD91: doFreeResource (resource.c:872)
>        by 0x45DE56: FreeClientResources (resource.c:1138)
>        by 0x45DF06: FreeAllResources (resource.c:1153)
>        by 0x43E3BD: dix_main (main.c:321)
>        by 0x30D70206FF: (below main) (libc-start.c:289)
> 
> Signed-off-by: Adam Jackson <ajax at redhat.com>
> ---
>  hw/xwayland/xwayland-output.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
> index 155cbc1..7e5484c 100644
> --- a/hw/xwayland/xwayland-output.c
> +++ b/hw/xwayland/xwayland-output.c
> @@ -188,8 +188,6 @@ void
>  xwl_output_destroy(struct xwl_output *xwl_output)
>  {
>      wl_output_destroy(xwl_output->output);
> -    RRCrtcDestroy(xwl_output->randr_crtc);
> -    RROutputDestroy(xwl_output->randr_output);
>      free(xwl_output);
>  }
>  

Would it be possible to harden the *free*function ?
IMHO that would be a better solution because it would
avoid futher trouble when ppl reintroduce that sequence
by accident.

re,
 wh







More information about the xorg-devel mailing list