Opened 10 years ago

Closed 2 years ago

Last modified 12 months ago

#9590 closed defect (outdated)

wxApp at computer shutdown (MSW, others?)

Reported by: arst Owned by:
Priority: normal Milestone: 2.8.8
Component: GUI-all Version: stable-latest
Keywords: wxApp system shutdown WM_ENDSESSION Cc:
Blocked By: Blocking:
Patch: yes

Description

This improves on the handling of system shutdown notifications (WM_ENDSESSION on Win32).

The previous code had a couple of problems: It did only destroy one TLW (an app can have several), and it destroyed the wxApp object before final destruction of any pending wxWindow. The patch to corrects both.

ATS

Attachments (1)

app-patch0.patch download (795 bytes) - added by arst 10 years ago.

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by arst

comment:1 Changed 10 years ago by vadz

  • Patch set
  • Status changed from new to infoneeded_new

Shouldn't this be replaced with the changes of r53186 and r53323 from the trunk? Could you please test if they fix your problem?

comment:2 Changed 10 years ago by arst

  • Status changed from infoneeded_new to new

There are two ways to approach this:

  • Close each TLW window properly (my patch), empty event queues and call wxApp::OnExit. A proper shutdown so to speak.
  • Ignore the shutdown signal (as done by trunk when hiding the MSW window handle).

With the first one the app can save any state it needs and app settings will not be lost.

Really, the first one is a proper solutuion and the second more of a hack.

I've been using 1 for some weeks now without problem so far.

Regards
ATS

comment:3 Changed 10 years ago by vadz

  • Status changed from new to infoneeded_new

You've obviously missed the part where it was discovered that Windows kills (not waits for termination, not closes by sending WM_QUIT or whatever but simply terminates immediately) the program during shutdown as soon as its last window is destroyed. Please see the comment in wxApp::OnEndSession() and the thread about it on wx-dev.

Of course, your patch is not worse than the current code for 2.8 (where no code is executed on shutdown at all) but the trunk version is still better, unless I'm missing something. If I do, please let me know what exactly.

comment:4 Changed 10 years ago by arst

  • Status changed from infoneeded_new to new

The patch empties any pending events after doing forceful close
on the window. Then it makes sure pending objects are deleted.
This happens for each open TLW. Then it triggers wxApp::OnExit.
It has worked OK so far.

The difference is maybe that one destroys the windows (by
calling DeletePendingObjects()) _before_ returning from
the WM_ENDSESSION handler.

If left to the idle handler (where wxWindows are usually destroyed),
there could elapse enough time for a force shutdown to happen. If
still inside the original message handler, I wonder if forceful
shutdown happens.

There's a good overview at this page:

http://msdn.microsoft.com/en-us/library/ms700677.aspx

There seems to be reasonable time limits both in normal and forced
shutdown.

The merit of the patch is that it does an ordered shutdown and
lets the app persist it's settings (toolbars, layout and so on).
It does not have seconds to do this, but probably milliseconds
at least.

wxApp is the creator of app windows and it's reasonable for it
to outlive the windows it has created. It's not good application
logic to call wxApp::OnExit while it's windows still exists.

Regards
ATS.

comment:5 Changed 10 years ago by vadz

  • Status changed from new to infoneeded_new

No, once again, it has been experimentally proved that the application is immediately terminated when its last window is destroyed. There is no timeout whatsoever. And while you won't find the description of this in the official Microsoft documentation (I'd be ashamed to document behaviour that stupid too) you can find references to this in the blogs of Microsoft engineers. I believe that a link describing this behaviour in details was given in the thread I mentioned above, have you read it?

comment:6 Changed 10 years ago by arst

  • Status changed from infoneeded_new to new

If it's been tested that closing the windows, emptying event queues and running destructors *before* leaving the WM_END_SESSION message handler leads to premature shutdown, than that is so.

Really quite strange, shutting down an app while still processing shutdown message, with no timeout margin.

I haven't read this thread on wx-dev (link?).

BTW, I'm doing most development on XP and this is where I experienced app crashes on shutdown.

I'll test SVN code and see if it works OK with XP.

Regards
ATS.

comment:7 Changed 10 years ago by vadz

  • Status changed from new to infoneeded_new

Ok, please reopen if you still have any problem with svn code, thanks.

comment:8 Changed 2 years ago by oneeyeman

  • Status changed from infoneeded_new to new

I think Vadim meant to close this ticket as he wrote "Please re-open" instead of changing its status.

Hopefully he will chime in and close in the next couple of days. Otherwise I will do it for him.

comment:9 Changed 2 years ago by vadz

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

comment:10 Changed 12 months ago by Vadim Zeitlin <vadim@…>

In 01fac4b74/git-wxWidgets:

Delete windows before application on session end in wxMSW

When WM_ENDSESSION was received by the application, the wxApp object
itself was shut down by calling OnExit() on it before all the TLWs were
destroyed, which could be completely unexpected as during normal
shutdown the order of events is exactly the reverse.

In practice, this resulted in crashes in any application whose main
window close event handler or dtor touched wxTheApp in any way (e.g. to
save any configuration in the global wxConfig object destroyed by
wxApp::OnExit()).

See #9590 (sorry for missing the point before, ATS).

Note: See TracTickets for help on using tickets.