Finding and Fixing 'Invalid Address' Errors Caused by Plugin?

Hi All,

I am working on a small plugin for my own use and having some trouble with repeated ‘bugsplats’. I know its impossible to diagnose the specific issue from afar without knowing anything about the plugin, so I’m more wondering if there is a ‘best practice’ that is used to identify, track and resolve these types of errors that folks use and they would be willing to share?

My specific issue at the moment is with a small personal plugin I am making to help me automate and speed up some of my own workflow. The crashing seems a bit ‘irregular’ - that is, sometimes the plugin works great and as expected, and then sometimes it errors on me and ‘splats’. As far as the specific error giving me an issue at the moment, I have reviewed the crash log files (on my Mac OS they are saved in ~/Library/Logs/DiagnosticReports/…) and they seem to show the same (or at least similar) error pretty consistently for each ‘splat’. Sample header:

Process:               SketchUp [8560]
Path:                  /Applications/SketchUp 2019/SketchUp.app/Contents/MacOS/SketchUp
Identifier:            com.sketchup.SketchUp.2019
Version:               19.1 (19.1.173)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           SketchUp [8560]

OS Version:            Mac OS X 10.14.3 (18D109)
Report Version:        12

Crashed Thread:        0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [8560]

VM Regions Near 0x10:
--> 
    __TEXT                 000000010369a000-0000000103ec7000 [ 8372K] r-x/rwx SM=COW  /Applications/SketchUp 2019/SketchUp.app/Contents/MacOS/SketchUp

Application Specific Information:
Performing @selector(invokeCommand:) from sender NSMenuItem 0x600002131c20.
.
.

etc…

the Exception Type ‘EXEC_BAD_ADDRESS (SIGSEGV)’ and Code: ‘INVALID_ADDRESS at …’ seem to be the issue in all the crashes logged that I can see. Can anyone shed a little light on what those items mean and how I might go about sussing out the offending code based on those errors? Or are those errors too vague to know what they are referring to? Google searching those error types didn’t yield much for me unfortunately.

Oddly, if a file crashes when I run the plugin and I just simply open it back up and try again - it then will work fine almost every time.

Any thoughts or suggestions on where / how I might go about cleaning up these issues would be greatly appreciated - or if there is a resource that you might think would be helpful to review when it comes to error-fixing or building code to be more robust against this sort of thing, that would also be really appreciated for the future.

thanks!
-Ed

Those exceptions come from the OS when code tries to read or write data from an illegal address in memory (“illegal” in this case meaning somewhere that hasn’t been assigned to that code as data space). Most often, this indicates the code is trying to use a pointer that has not been correctly initialized to a legitimate address value. This may indicate an improper action in your code, a conflict with some other extension (especially over observers), sometimes an issue with your graphics adapter’s OpenGL support, or an outright bug in SketchUp itself.

In general, one needs access to the source code of the app to make sense of the rest of the log report. If you included contact information and submitted the BugSplats, someone from the Trimble team should get back to you.

Unfortunately, when the culprit is a plugin the log’s traceback will just reveal that something went astray while the Ruby interpreter was running code, it won’t indicate what Ruby file or line was involved because the OS doesn’t know that and Ruby has to be killed off when the violation occurs, so it also can’t report anything.

The general best practice is therefore to start by turning off all other plugins/extensions to eliminate the possibility of a conflict with them. If that eliminates the problem, then you can progressively turn them back on until you find which one(s) cause the conflict. If the problem persists (or once you have found a conflicting extension) you can comment out parts of your extension until the issue goes away, then try to figure out what you are doing wrong in that section. Yes, that can be an extremely tedious and time-consuming process, and may not lead to a clear resolution if there is a bug deeper in SketchUp.

1 Like

Hi @slbaumgartner,

Thank you very much for the detailed response. I appreciate the input. That process you outline makes sense. My difficultly here is because the issue happens so erratically, I can’t seem to re-create the crash in order to zero in on the issue. That description of the error code is helpful though and something for me to think about as I continue to build out the tool.

Do you ever use a ‘logger’ to a file in a case like this to keep a more detailed watch over the code process? I’ve done that with some python projects in the past but I haven’t tried to do it through Ruby-via-Sketchup. Perhaps I’ll hunt around and see if there is a way to implement something of that sort.

thanks!
-Ed

You could easily write a logger in Ruby. Yes, I’ve done that on occasion when there is a difficult to reproduce bug. It is also common practice to puts messages, but that is of no value if the bug crashes SketchUp.

You might have a look at the logger stdlib, see
https://msp-greg.github.io/ruby_2_5/logger/Logger.html

Also, while working with some testing, I set up a UDP socket that I wrote to from SketchUp, and had a stand-alone Ruby console window open with a receiver. Check the receiver code

Send code is a bit messier, as it was used in a Minitest reporter

Sometimes file IO (loggers) may get buffered, etc, and the crash may interfere. UDP is pretty much immediate.

I did md links to the files, otherwise they display as truncated ‘box-thingies’…