CrossMgr window may freeze on close operations and lose data

[tjsr]

A variety of scenarios have been encountered where the CrossMgr window(s) may freeze and/or crash, often during the process of closing windows or files, and as a result lose all data not saved, with the current event not being saved to disk. This loss of data includes passings entered manually or received from an electronic timing device.

Other lost data includes event settings/properties and data file column mappings.

To Reproduce
To be confirmed.
Has been experienced when:

• Closing the current race file.
• Exiting the application
• Closing the unassigned passings window

Expected behavior
When any crash occurs, I want the system to always at least make an attempt to save the current data file to a temporary or recovery/recoverable file.

Desktop (please complete the following information):

• OS: Windows 11

Additional context
This is a critical bug - experienced about six times on 31/01/25 including during an event. The loss of data is a significant issue.

I'll spend more time replicating in the morning and getting some stack traces.

Additionally, the lack of any console or debug windows or logs makes it difficult to determine what is going on underneath - this is a feature I'm going to need to add to aid in debugging.

[tjsr]

I have spent at least the last 7 hours trying to debug this issue and identify exactly what is going on and causing it.
As best as I've been able to determine, there are four listener threads/sockets that continue to be held open, polling every 0.5s/2s, but which never receive a shutdown command. The issue still happens from the 3.1.65 tag.

It appears as though there is some shutdown command that is supposed to occur to stop some running processes and have the main window stop waiting on some kind of handle - I just can't identify it yet.

I've tried picking a few random points in the commit history, going back to find a version that doesn't have this problem, but as far back as 3.1.30 I still encounter this issue.

[esitarski]

Some more input: Crashes/hangs on exit generally happen if wxpython throws an exception. I suspect that wxpython exceptions mess up its event loop, and this prevents it from exiting properly. This can cause a loss of data if you make a change then immediately exit. There is a thread that periodically flushed CrossMgr data to disk. For example, if you experienced the Distance edit bug, CrossMgr may have problems exiting. wxpython used to handle internal exceptions without exit issues. All CrossMgr threads are flagged as "daemon", so they terminate with the main thread. This should not be a problem.

…

On Fri, Jan 31, 2025 at 11:18 PM Tim Rowe ***@***.***> wrote: I have spent at least the last 7 hours trying to debug this issue and identify exactly what is going on and causing it. As best as I've been able to determine, there are four listener threads/sockets that continue to be held open, polling every 0.5s/2s, but which never receive a shutdown command. The issue still happens from the 3.1.65 tag. It appears as though there is some shutdown command that is supposed to occur to stop some running processes and have the main window stop waiting on some kind of handle - I just can't identify it yet. I've tried picking a few random points in the commit history, going back to find a version that doesn't have this problem, but as far back as 3.1.30 I still encounter this issue. — Reply to this email directly, view it on GitHub <#157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGXKOIMSHED43HYGKU6ZL2NRDHTAVCNFSM6AAAAABWHOKAMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRYG42TQNZYGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Edward Sitarski