Skip to content

Avoid access to free'd memory after window closing.

ManoloFLTK requested to merge ManoloFLTK/libdecor:safe_window_close into gtk_cairo_single

When libdecor is used with several closeable windows, the present code of the GTK plugin may access two pieces of free'd memory after a window gets closed. This MR proposes a small code change to prevent such memory accesses.

To show the problem, I attach 3 modified source files intended to transiently replace demo.c, libdecor.c, and libdecor-gtk.c : libdecor-gtk.c libdecor.c demo.c

Program demo.c is modified to open a second window titled window2 and to allow the program to continue running after window2 gets closed. Files libdecor.c and libdecor-gtk.c are modified with printf statements that show the illegal memory accesses under scrutiny.

Here is how to proceed, once demo.c, libdecor.c and libdecor-gtk.c are replaced by their temporary version, to trigger the memory problems :

  • build libdecor with its three modified files
  • run demo with LIBDECOR_PLUGIN_DIR pointing to the dir containing the just built libdecor-gtk.so
  • rearrange the 2 windows so that window2 is in front and with its top-right corner above the other window
  • close window2 with the mouse (not with escape key)
  • slightly move the mouse
  • hit escape key to close the remaining window
  • consider the end of demo's output which should be similar to this :
wl_surface_destroy(0xaaaae98bbde0)
wl_surface_destroy(0xaaaae98ca190)
libdecor_frame_unref: free(0xaaaae99a4830)
will dereference 0xaaaae99a4830
pointer_motion needs 0xaaaae98bbde0 to be a wl_surface
Segmentation fault

  1. the "will dereference" line arrives after the "libdecor_frame_unref" line with the same pointer value. This shows that a dereference after free operation took place.

  2. the "pointer_motion needs 0xaaaae98bbde0 to be a wl_surface" line arrives after line "wl_surface_destroy(0xaaaae98bbde0)". This shows that a call to own_surface(a_wl_surface) occurred after the corresponding wl_surface has been destroyed. This sometimes, but not always, creates a segmentation fault, as in the run whose output was copied above.

If line #2214 of libdecor-gtk.c

#define NEWCODE 0

is changed to

#define NEWCODE 1

and the operations above are repeated, the errors numbered 1) and 2) above don't happen anymore.

I therefore suggest to commit the modification of libdecor-gtk.c present in this MR.

P.S.: a very similar problem occurs with libdecor-cairo.c, another MR to J. Adahl's libdecor repo (#105) has been set up.

Edited by ManoloFLTK

Merge request reports