Running Mojave on a 2016 MBP. I’ll be in the middle of a line of code in Xojo, suddenly the UI and entire Xojo app just disappears with zero warning or messages. Sometimes, after a minute or two, I’ll get the “Xojo quit unexpectedly” message.
This happens fairly often and has led to lost code, lost productivity and a lot of frustration. Sample crash log is here .
Has this been happening to anyone else? Any obvious remedies other than falling back to a previous version? For now I have been coding on Windows (which doesn’t seem to have this problem) and then compiling on Mac, but it makes debugging for Mac apps frustrating.
@Robert Birge Thanks, at least good to know I’m not alone! I don’t have the bandwidth to download another Xojo version at the moment but I will when I can.
@Christian Wheel I actually have much less problems with 2019r1 on Mojave (10.14.4) than I had with 2018r4. Your crash report shows that the crash occurred when testing if you MBP has a TouchBar or not. As I have an oldish iMac, I may not run into such problems.
Maybe you can try to run your app in 32-bits to see what happens.
@Paul Rodman Unfortunately, each Xojo release has its own plague! For me, 2018r4 just wouldn’t load my home-made plugin so it was a no-go. I can use either 2018r3 or 2019r1 but that is only my personal case and it can be much worse for some!
Sounds like we need a 2019r1.1 ASAP… I hope Xojo inc is considering it! BTW for those using my cell merging listbox, that listbox leak would be a real killer.
It would be nice to have a release where no new bugs in pre-existing functionality was introduced!
The question is - is the issue with Xojo 2019r1, or with Mojave (discounting the Linux performance issues for now)? I can run for hours under 10.13.6 with no degradation. However, my main project and 19r1 on Mojave are a royal PITA after an hour or so of normal working.
It seems like the OS is trying to get the touchBar items for an NSTextInputContext that’s already been deallocated - it’s crashing on respondsToSelector: during candidateListTouchBarItem in NSTextInputContext (maybe deallocated in the deactivate call that precedes the crash or something?). A quick Google search turns up similar issue in Chromium.
(I was about to say that I haven’t had any crashes, and then Xojo crashed. Different reason though. (https://xojo.com/issue/55611)>]-report- )
I know you don’t want to disable the TouchBar code in your application, but I think you should at least try for a while; just to rule it out. After all there could be some kind of weirdness when you come back from a Xojo based application that interacts with the TouchBar, to Xojo which doesn’t.
Worst case scenario is that it doesn’t make any difference; however it might just solve your crashing issues. If it does when can then figure out the best route to go about solving it.
The TouchBar was very poorly implemented when it first launched, with crashes on non-TouchBar machines being attributed to the TouchBar software trying to interact with non-existent TouchBar hardware.
That would make sense then that Xojo isn’t anticipating being asked for touchbar items and releases the input context on deactivate (pure speculation of course). Apple assumes that everyone wants to provide items for the touch bar.
Does the IDE use TextInputCanvas? That has an override to return nil for inputContext if the view is not editable.
That would make a lot of sense if Apple isn’t getting the context into a local variable and operating on that, but rather using a function call result for each new call, and assuming it’s never going to be nil.
So essentially once deactivate is called, the next call goes to a nil object and boom… That is, if the IDE uses TextInputCanvas.