There's a regression in FMSLogo 8.0.0 which makes FMSLogo crash (dereference null) if an instruction list callback is run while FMSLogo is shutting down. The actual mechanics are that the main window has been deleted and wxWidgets runs a queued event. This could be a callback from WINDOWFILEEDIT, SETTIMER, MOUSEON, KEYBOARDON, etc.
The impact of this is low; since FMSLogo was exiting, the crash does not cause any data loss. The impact is more emotional: it looks bad and it is a regression.
This is reproducible in FMSLogo 8.0.0 but not in FMSLogo 7.7.0. I believe this was introduced by upgrading wxWidgets from 3.1.0 to 3.1.3. Specifically, I think wxWidgets changed the way they process events (intentionally or not) to allow events to be processed after the window has been destroyed.
For reference, the top of the stack when it crashes looks like:
#0 0x00444ed2 in CMainFrame::GetCommander (this=0x0) at mainframe.cpp:1105
#1 0x0041b5c4 in UpdateUiExecutionState () at fmslogo.cpp:702
#2 0x004171b5 in start_execution () at eval.cpp:2520
#3 0x004172ae in do_execution (logocommand=0xa1c2e0 <edit_editexit> L"fd 100") at eval.cpp:2563
#4 0x0043fd8b in checkqueue () at logoeventqueue.cpp:333
#5 0x0041b0a4 in CFmsLogo::OnIdle (this=0x82f9f50, IdleEvent=...) at fmslogo.cpp:552
How Reproducible
Every Time
Steps to Reproduce
windowfileedit "file [ textscreen ] byeWhat Happens
FMSLogo disappears and then Windows says that FMSLogo has stopped working (it crashed).
Expected Result
FMSLogo disappears cleanly.
I have committed a fix [r5623]. Since this is a regression from the previous version, I will release this as a micro release: FMSLogo 8.0.1.
I wasn't able to fix this cleanly, I only fixed the ones that I knew how to reproduce.
Related
Commit: [r5623]