I use a MUTEX in a project that has always behaved as it should until 15r3.1. Here’s the code from the main window’s Close event:
If App.agentMutex <> Nil Then
When debugging under 15r3.1, I get an error indicator at the “App.agentMutex.Leave” line. However, there’s no indication as to what the error is. If I continue, the project exits properly, but I’m concerned that there’s something going on that I’ve missed elsewhere.
Are you sure you had entered the mutex earlier?
Btw, with code like that, I like to nil the reference too. It doesn’t much matter in App.Close, but I still do it for consistency. My thinking is, if it exists, it’s active/running/etc.
Yep - quite sure I’m in it as the first item in App.Open is:
agentMutex = New Mutex("bruAgent")
If Not agentMutex.TryEnter Then
MsgBox "Config Tool Already Running" + EndOfLine + EndOfLine + "BRU Server 2.0.5 Agent Config Tool Is Already Running. Exit the current config tool and try again."
If the entry failed, the app would be running to get to the window’s Close event :). Also, trying to start a second instance recognizes the MUTEX state.
As I mentioned, the exception isn’t displayed - just the pause on the line and the little bug icon in the margin.
This does’t occur in 15r2.4 or 12r2.1 and the app otherwise runs exactly as expected…
Platform? I just tried to recreate this in a simple project on the Mac and could not.
Mac OS X 10.9.5, 10.11.1.
So there has to be something else going on. Is it a project you can share?
Wrap the code in a try/catch using RuntimeException and then break at that point. You should be able to inspect the variable and see what the error was.
Catch ex as RuntimeException
Put the App.agentMutex.Leave in CancelClose() instead of Close()?
Thanks, @Greg O’Lone.
It’s an “IllegalLockingException”. The Error is 3, and the message is “The thread which Signaled the Mutex must be the thread to Release the Mutex”. However, this project doesn’t use threads.
Please file a bug report with a project so that we can look into this further.
What kind of project? And where do you enter the mutex?
It’s a standard Desktop app. The reason for the MUTEX is that users rename the old copy of the app before installing a new version in too many instances and the two versions are not compatible at the core I/O level.
The entry point is in App.Open. The Leave is in WMain.Close. There are no threads.
@Joe Ranieri - the project is dependent on our full client / server product installation to function. Let me see if I can isolate the communication code and the installation checks.
Also, the issue doesn’t seem to affect the app when it’s just running. Only when it’s run in the OS X debug mode.
This just made me think of something - maybe the Leave should be in the App.Close instead of the WMain.Close. I’ll make that change and see if it sorts it.
Done - that was it. By moving the Leave to App.Close, the issue is completely gone.
A bug report would still be nice so that it can be investigated and fixed properly.