Keeps occurring. Just sent a BugSplat report, maybe @Colin can shed some light on the problem. Started with the upgrade to SU2021.
And how did you installed the update?
This is MacOS (Mojave), so the installer puts a dialog box on the screen with arrows to drag. Used the same method as all other upgrades.
Picture is worth a thousand words, as they say …
Maybe a Mojave issue…
Rebuilt system with fresh MacOS load. No other applications. From the many other posts, I strongly suspect SU.
I looked at the three bugsplats, and two seem to be related to the 3DX drivers. Can’t make sense of the other one.
The crashes say ‘3DxSketchup Plug-in: Active model not available (invalid data)’. I wonder if it is the exact action you are doing that triggers the problem. Is there a pattern to what you are doing when the crash happens?
By the way, from the crash log I can tell that SketchUp is running from the right location.
I do have a SpaceNavigator (Driver Version 10.6.5) loaded. As far as device behavior, I do not understand what this means:
I am using the device as I used it in earlier versions of SU. My only option is to remove the device and driver from the system. This would degrade my productivity greatly. Feel like I am, as they say, between a rock and a hard place.
As far as a pattern to the crashes. This morning I had ~15 crashes. The only commonality was ~5 occurred when I closed the file (not SU). Hope this helps.
I see all posts, and know what you have gone through with drivers and other things.
My guess is that there is a combination of things going on, where the Space Mouse is making an assumption, and either macOS, or SketchUp, are replying with something unexpected. The Space Mouse drivers shouldn’t then cause a crash, but also SketchUp should have replied with the right information.
Finding a combination of actions that always causes a crash would give us and 3DX guys a chance to either fix the incorrect information being returned, or at least take that wrong information and not let it lead to a crash.
Let’s check with @TheOnlyAaron. He uses Space Mouse more than anyone else at SketchUp, and may have had crashes that he didn’t associate with a Space Mouse Enterprise action than he had done.
I read your later reply. I’m not sure why closing the file would affect the Space Mouse, but I will try some tests involving closing files. If you have a file that gives lots of crashes when closing, can I try the file?
Actually happened on a variety of files. Several real data files. Once the crashes started, I closed the actual data files and opened a series of test files with minimal geometry. I was trying to find a common configuration to reproduce the crash. This was unsuccessful, completely random. I was flailing about, restarting SU, restarting the OS. I could open a file that previously caused a crash and it would behave normally. Started to doubt my own sanity at some point.
I did take the data files over to Windows 10 (SU2010), with the same SpaceNavigator (different driver, of course) and could NOT generate any crashes. I believe there is an important message here.
It is somewhat off topic, but with regard to Mac versus Windows, I argue that ‘I’ work faster on Mac.
I certainly can’t say the same …
Sure, you can say that Colin works faster on Mac, I don’t mind.
I don’t use a Mac, but I understand that a working SketchUp 2021 (and/or MacOs 11) driver and plugin for 3D Connexion devices has not yet been released. A well behaving beta driver mentioned in another thread.
I tried various older versions, newer versions and the beta. The only driver that is somewhat usable on my system is 10.6.5.
I am still getting the random crash. Happened a few minutes ago, I sent the BugSplat report. Any advice? And this happened on Windows. So now, the problem is on both MacOS and Windows. And this is with two different SpaceNavigator devices. Thanks …
I have also seen this crash and reported it on the 3DConnexion forum. Time will tell whether they do anything about it…
The crash occurs with the latest Mac beta driver too. It is definitely still beta, with various bugs reported on the 3DC forum. It seems that nearly all of their attention is focused on figuring out how to pass modifier keys through to apps from their devices that have customizable buttons, and “lesser” bugs such as this are on hold.
I started a new file, thinking the previous one was corrupted. Another BugSplat, just sent. Cannot use SU with this problem. Very frustrating, hope this does not happen to others.
I’m a little late to this thread party, but regarding crashing when closing files, I’ve sent a slew of nastily commented bug splats recently because I’m at my wits’ end with SU2021. When I read the stack trace of the crashed threads in the Mac crash reporter, I see all kinds of wonky coding going on in the stack trace. I say this because you may be looking at the 3D Connexion drivers as the source of issues, but that may just be a red herring… I’ve had the closing of a file result in a crash in an NSColorWell drawing routine that has called into Ruby for some reason. And SU really doesn’t like files on a mounted network drive since I’ve seen crashes in the SketchUpModelReader which is C++ code called from Obj-C code. I feel like the coding team is cobbling things together from a mix of C, C++, Obj-C and Ruby code and not properly bridging between them. My 2 cents because I’m seriously pissed off at this current SU 2021 build.