2019 r1 has been near unusable on Mac

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.

Same Issue as here?: https://forum.xojo.com/conversation/post/409287

@Sascha S Very similar crash log for sure! The issue presents differently from that post though. For me it happens while typing code into Xojo’s IDE.

This same problem happened to me so I switched back to 2018R4. No problems. Have you tried 2018R4?

@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, I also noticed that 2019R1 works fine for me on High Sierra. It is Mojave that causes the problems I think.

@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.

I was living with the crashes until I read about the horrible memory leaks in listbox. Now I’m back with 2018r4 and it’s malfunctioning web stuff.

@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!

I’m under El Capitan and didn’t have any crash with Xojo 2019r1 .

2019r1 and 10.14.4 working fine here on CMP/32G/NVME.

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!

  • Karen

@StphaneM - Yes it has a touchbar. And it’s the Xojo IDE that is crashing so there’s no 32-bit option.

@TannerL - Am I correct in assuming CMP = Cylinder Mac Pro?

@RobertBirge - Does your Mac that had issues with 2019 R1 have a touchbar?

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.

My Macs are all 2013 vintage (Canister, rMBP, and Mac Minis), so no touch bar here.

Does it still crash if you disable the touchbar?

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- )

@jim mckay I will give that a try when I get back to my Macbook, but it’s not a viable workaround for me as my app implements custom touchbar buttons.

In that case, maybe you could just disable it in Xojo and see if that helps.

I don’t have a touchBar Mac, so I can’t test the given instructions…

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.