• Join/Login
  • Business Software
  • Open Source Software
  • For Vendors
  • Blog
  • About
  • More
    • Articles
    • Create
    • SourceForge Podcast
    • Site Documentation
    • Subscribe to our Newsletter
    • Support Request
SourceForge logo
For Vendors Help Create Join Login
SourceForge logo
Business Software
Open Source Software
SourceForge Podcast
Resources
  • Articles
  • Case Studies
  • Blog
Menu
  • Help
  • Create
  • Join
  • Login
  • Home
  • Browse
  • FMSLogo
  • Bugs
FMSLogo

FMSLogo 8.0.0 can crash if callback instruction list is run while exiting

A Logo programming environment for Microsoft Windows

Brought to you by: david_costanzo
  • Summary
  • Files
  • Reviews
  • Support
  • Tickets ▾
    • Feature Requests
    • Bugs
    • Support Requests
  • Discussion
  • Code
Menu ▾ ▴
  • Create Ticket
  • View Stats

Group

  • v_6.06x
  • v_6.07.X
  • v_6.08.X
  • v_6.10.X
  • v_6.11.X
  • v_6.13.X
  • v_6.22.X
  • v_6.25.X
  • v_6.26.X
  • v_6.27.X
  • v_6.28.X
  • v_6.29.X

Searches

  • Changes
  • Closed Tickets
  • Open Tickets

Help

  • Formatting Help

#557 FMSLogo 8.0.0 can crash if callback instruction list is run while exiting

v_6.06x
closed-fixed
David Costanzo
None
5
2021-01-17
2021-01-17
David Costanzo
No

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

  1. Run windowfileedit "file [ textscreen ] bye
  2. Click "OK" when prompted if you really want to exit FMSLogo.

What Happens
FMSLogo disappears and then Windows says that FMSLogo has stopped working (it crashed).

Expected Result
FMSLogo disappears cleanly.

Discussion

  • David Costanzo

    David Costanzo - 2021-01-17
    • status: open --> closed-fixed
     
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  • David Costanzo

    David Costanzo - 2021-01-17

    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]

    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.

SourceForge
  • Create a Project
  • Open Source Software
  • Business Software
  • Top Downloaded Projects
Company
  • About
  • Team
  • SourceForge Headquarters
    1320 Columbia Street Suite 310
    San Diego, CA 92101
    +1 (858) 422-6466
Resources
  • Support
  • Site Documentation
  • Site Status
  • SourceForge Reviews
SourceForge logo
© 2026 Slashdot Media. All Rights Reserved.
Terms Privacy Opt Out Advertise
mdb logo