Perhaps because the computer was previously used at a university and I guess the IT guy there may have configured it that way.
It is possible to change to a case-insensitive MAC OS, but it is not simple…
If you have a good computer shop nearby, then talk to them before trying anything yourself…
Okay.
Well then i guess thanks for figuring out.
Cheers
I’m still curious as of why this would cause a crash. I can imagine a lot of developers assume they are writing for a case insensitive system and don’t follow a good naming convention, but wouldn’t that still just lead to load errors? I wouldn’t be surprised if compiled code in SketchUp’s core had issues with case-insensitivity, but why is there an issue with extensions that is expressed as anything more than RuntimeErrors?
That’s a good question. The fact that SketchUp posts that message says the developers are aware of a situation that can cause a fatal error while loading extensions. But what situation?
In the general app case, the issue is usually that the developer was careless about the case of library names the app links - e.g. the project setup says to link libFoo.so whereas the actual library is libfoo.so. On a case-insensitive filesystem this doesn’t matter as these two names are equivalent. But on a case-sensitive one they don’t match and the linker can’t find the specified library. This issue can be transitive: if the app links a library that contains this error when loading a second library the app is an innocent victim!
So, one way this could happen while loading extensions is if the extension uses a compiled-C library and the extension developer was similarly careless about names when setting it up. There are developer tools that can be used to look for and then repair case-sensitive mismatches, but a) that’s a task for experts who know what they are doing, and b) it really should have been taken care of by the original developer.
1 Like
If you use:
$".sort
in the Ruby Console [Note that I can only check this on a PC at the moment] -
you can also pass it through a grep to limit the output -
e.g. $".grep(/rb$/).sort
$".grep(/rbe$/).sort
You’ll see that all of the loaded RB files’ paths keep their characters’ “cases” intact etc, but any compiled RBS or RBE files’ paths are all forced into lowercase.
Perhaps this is the nux of the issue ?
I ran these commands in Ruby Console on my Mac and noticed two strange things.
First, as you say, in the second case (the grep for elements ending in rbe), all the paths are all lower case whereas in the first one they are correctly mixed case. I don’t know what the extension loader uses them for, but on a case-sensitive filesystem they are wrong. For example, the standard folder for extensions on Mac is
/Users/<userid>/Application Support/SketchUp 2019/SketchUp/Plugins
but in the grep for rbe, they all appear as
/users/<userid>/application support/sketchup 2019/sketchup/plugins
On a case-sensitive filesystem those are not going to match!
Second, I noticed in the grep for elements ending in rb, although the path cases are correct, I get numerous ones ending in “.rbe.rb”. I have no idea why those are in $", do you?
Edit: one theory is that the decrypter creates temporary .rb files from each .rbe, loads the resulting ruby, and then deletes the decrypted file. It may give these files the .rbe.rb extension? But if that’s so, what are the case-flattened entries for?
2 Likes
It only happens on the rare occasion when SketchUp crashes during the load of extensions, and then restart.
If you choose not to load them, none of the extensions will load (even the native), resulting in a blank extension manager window(!)
Was reported as SU0063, some time in the past
1 Like
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.