Opened 6 years ago

Closed 6 years ago

#14602 closed defect (fixed)

g_captureWindow is not set to NULL when window destroyed in wxGTK

Reported by: shaurz Owned by:
Priority: normal Milestone: 2.9.5
Component: wxGTK Version: 2.9.4
Keywords: Cc:
Blocked By: Blocking:
Patch: no


When a window is destroyed that currently has capture, g_captureWindow is not set back to NULL. This can obviously cause crashes but is difficult to reproduce reliably (we have seen them though).

The fix is to add the code below to wxWindowGTK::~wxWindowGTK in src/gtk/window.cpp:

    if (g_captureWindow == this)
        g_captureWindow = NULL;

Change History (7)

comment:1 Changed 6 years ago by shaurz

Also I forgot to add that gs_postPopupMenuFocus also needs the same treatment!

    if (gs_postPopupMenuFocus == this)
        gs_postPopupMenuFocus = NULL;

comment:2 Changed 6 years ago by vadz

  • Status changed from new to infoneeded_new

Well, it's an error to destroy the window which has capture as you should already know from the assert you should be getting in this case (you do get it, don't you?). And it's really something that should be fixed in your code.

Do we really need to work around this in wxWindow dtor?

As for gs_postPopupMenuFocus, this is something that just doesn't exist, so I guess you mean something else, but what?

comment:3 Changed 6 years ago by shaurz

  • Status changed from infoneeded_new to new

I guess gs_postPopupMenuFocus has been removed now (our build of wx is using

We do not get any assertion errors, instead the program simply segfaults. Adding this code to the destructor stops the segfault (and the code to set g_captureWindow does run - a debug print confirms it). Which assert are you referring to?

We found the problem when using the Python implementation of AUI when closing lots of panes very quickly.

In any case, in the interest of general robustness, it's not a great idea to leave global variables pointing to destroyed objects. It's a case of "this can never happen", and yet it does.

comment:4 Changed 6 years ago by vadz

  • Milestone set to 2.9.5

Maybe it crashes before the assert? Try running it under debugger and break on wxDefaultAssertHandler() (unless wxPython changes it? If so, break on wxSetDefaultAssertHandler() and then on whichever function is passed to it). It would be important to know what's going on here, if only to fix wxAUI bug, even if though I agree that it's better to keep running rather than crashing, so I'll add something like this to ~wxWindow.

comment:5 Changed 6 years ago by vadz

Can this be reproduced in any way that would allow me to test for it easily?

comment:6 Changed 6 years ago by vadz

OK, I still have no idea how do you manage to not get an assert from wxWindowBase::~wxWindowBase() when this happens but I'll add the check -- with its own assert. Please reopen if you manage to trigger it.

comment:7 Changed 6 years ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [73000]) Add check for destroying window with mouse capture in wxGTK.

We already have an assert checking for this at wxWindowBase level but it seems
that it wasn't always triggered somehow (maybe because we crashed before
getting there?), so do it sooner.

Closes #14602.

Note: See TracTickets for help on using tickets.