[lmi] Re: crash in wxFileHistory code

[Greg Chicares]

On 2009-03-09 22:31Z, Vadim Zeitlin wrote:
> On Mon, 9 Mar 2009 18:08:58 +0100 Vadim Zeitlin <address@hidden> wrote:
> 
> VZ> GC> Now I observe a sporadic crash in a similar situation.
> VZ> 
> VZ>  Unfortunately I couldn't reproduce the crash. It might be due to a
> VZ> difference in exception handling between MSVC and mingw32 but to be honest
> VZ> I don't see how is this possible. Looking at the backtrace I don't quite
> VZ> understand what's going on neither, it looks like m_fileMenus in
> VZ> wxFileHistory got corrupted somehow as otherwise I don't see why would the
> VZ> call to SetLabel() crash.
> 
>  For once I guessed the cause of the crash almost correctly: the list
> itself wasn't corrupted but it did contain the already deleted pointers.
> What happens is that ViewEx::OnCreate() calls DocManager().
> AssociateFileHistoryWithFileMenu() and normally OnClose() executes the
> matching DissociateFileHistoryFromFileMenu() call.

So far, so good.

> But if an exception is
> thrown from IllustrationView::Run(), OnClose() is never called and so the
> menu pointer remains in the list of the menus managed by wxFileHistory even
> though it's going to be deleted as part of the frame destruction process.

I think we've already fixed that, the same way this other problem was fixed:

http://lists.nongnu.org/archive/html/lmi/2009-03/msg00037.html
|
| [...] Now, IllustrationView::OnCreate()
| returns 'true' iff a view has been created. If 'true', then the view
| exists, and [...] works correctly. If 'false', then no view exists,
| and none ever did; returning 'false' to wx was correct, so there's
| no problem. (Returning 'false' to wx when a view did exist was a
| real problem.)

IOW, AIUI, the underlying cause of both these observable problems was that
IllustrationView::OnCreate() wasn't safe. Formerly, it could have let an
exception escape, thus fooling wx by not passing back any return value; or
it could have returned an incorrect value, thus lying to wx. Now it always
returns, and the return value is 'true' iff a view has been created. So I
think we've removed the ultimate cause of the observed problems.