Hello again. First off thanks to all for your quick responses to our earlier issue today. It’s nice to know there’s a helpful community we can rely on.
Another issue we’re experiencing: on MacOS High Sierra, our app will hang at a particular time. We know exactly how to reproduce the issue. We’ve tried to set breakpoints in parts of the code that may be executing like Timers and Shell events. None of the breakpoints activate and the app simply freezes. This occurs in both debug and release builds.
Is there a way to help us identify where in the code the issue may be occurring?
sounds like you may have a race-condition (if it were recursion, it would crash after a minute or two)
use some type of profiler (Im sure someone will reccomend on)… this might tell you where (approximately) the program is spending (wasting) all it time
When you force quite the application, it will generate a report and buried in that report will the function that it froze at. Once you’ve gotten the report, paste it here so we can help you track it down. Since Yosemite, Apple’s care with their OS updates has gradually gone down hill, so don’t be surprised if it’s an issue with High Sierra.
Thomas - we can reproduce the issue when running the app in debug mode in the IDE. Nothing happens when we click the Pause button. The app continues to run and the IDE does not pause execution.
Have you tried to add logging in the forma of currentMethodName at the beginning and end of each function? With this you can see what happening when the breakpoints don’t fire.
Do the hangs go away when you don’t do the thread? What exactly are you doing in the timers and threads?
I think I see that you do something with IPC in the app. Is this correct?
We’re not doing anything with IPC in the app. We do have a shell instance running and we are using HTTPSocket. The only way to reproduce the crash requires having the shell instance running so we can’t easy remove that. We’ll try removing the HTTPSocket code to see if that fixes the issue. We’ll also consider the logging you suggest. Thanks!
Ok adding logging helped us identify the code causing the hang: it’s the WriteLine() function in our Shell instance. Is this a known issue? We’re investigating now.
After doing some searching on the forum, we tried creating a thread and calling the WriteLine function from the thread. It didn’t make a difference. Somehow calling WriteLine() is locking up the entire app. We also checked the text that is passed to WriteLine() and it’s a small piece of JSON without any unusual characters. In fact, the exact same text is passed to WriteLine many times without issues, prior to the freeze occurring.
Clue: we have a timer that runs and send JSON to the shell. This timer was set to a 1000ms interval. When we set the timer to a 500ms interval, the app hung in just over half the time. Is there some sort of buffer that may be overflowing?
What’s strange is that in order to reproduce this hang, we have to send a particular command to the Shell that change the behavior of the shell app. Further, the command needs to be sent at a particular time. If we don’t send the command, the hang does not occur. If we send it earlier or later, the hang does not occur. If we send it at the right time, the hang occurs after some number of additional commands are sent to the shell. The timer I mentioned above control the frequency at which those additional commands are sent. The faster those additional commands are sent, the faster the hang will occur. So it seems that a particular command puts the app in state where it’s going to eventually hang, and then sending some number of additional commands triggers the hang. All commands are JSON strings sent via Shell.WriteLine().
This looks to be an issue with our Java app that’s running in the Shell. It’s locking up for some time and causing the Xojo app to freeze. Not a Xojo issue unless you consider the Shell instance locking up an issue.
In Xcode you can use “Attach to process ” in Debug menu. Then you can pause the process similar to Xojo and look at the current stacks in the used threads.
FYI we did identify the issue with the console app that was running in the Shell instance. It was some sort of deadlock related to thread wait/notify in Java. We actually couldn’t address the issue directly and ended up coding up a workaround. The app no longer locks up and the issue has gone away. It is strange, as I mentioned above, that a lock up inside the shell app would cause Xojo to hang as well.
“Synchronous shells block the main UI thread, even when they are in a thread themselves. For long-running shell processes, use one of the other shell modes instead.”