I'm absolutely aware of the fact that there is no clear solution available for my question, that's why I'm NOT asking why it does not work but what the intended behaviour is/how the current implementation is specified to work:
I have a wxFrame-derived class with a lot of sub-GUI-elements. On close wxFrame::Destroy() is called and I end up not only in destructor of my wxFrame-derived class but also in destructors of all these sub-elements. In this case all my windows are closed and the application exits properly.
Now under some condition this does not work: I can step throug wxFrame::Destroy(), it is doing the same as usual but afterwards no desctructor is called, the application stays alive and visible. I can try to close/call wxFrame::Destroy() several times in this situation, the result is always the same, the application stays alive and all windows are still visible and usable.
I personally would guess, it has to do with one of my sub-elements but I have no idea, which one/what could cause this behaviour.
So my question: how is wxFrame::Destroy() intendend to work, under what conditions would it reject such a call and would not destroy the related wxFrame?
wxFrame::Destroy() doesn't destroy the window immediately, it just marks it for deletion which will actually happen during the next message loop iteration, after all the pending messages are processed (this is important as some of these pending messages might have handlers referencing the frame about to be deleted). So the most common explanation of a problem like this one you're describing is that there is something generating events faster than they can be processed and so the message loop never becomes idle.
For example, in the older versions of wxWidgets, this could happen with wxEVT_PAINT events under MSW if you didn't repaint all the windows properly, i.e. didn't create wxPaintDC in your paint handler. wxWidgets 3 have added some workarounds which prevent this exact scenario from occurring, but something slightly more complicated could still happen.
To debug this, it can be useful to run Spy++ application and check if you see a never-ending stream of Windows messages to your application windows.