Access Violations in Sketchup's RubyVM during mouse events


we’re having an issue where after some time, we randomly get Access Violations in Sketchup’s Ruby VM , or to be more specific, in both rb_class_of during return RBASIC(obj)->klass; (when resolving ->klass, usually for calling enableVCB?) and in method_entry_get when trying to access the macro GLOBAL_METHOD_CACHE with a 0x0000’d klass.

All those calls result from (Windows) mouse events that go through Sketchup (where I don’t have a pdb to check what Sketchup is doing exactly) after we finish our tool operations.
Our current theory is that it is likely connected to tool pushing and popping (we’re using our custom placement tool in those cases), but it’s happening after we’ve finished all our operations, and as far as I can tell, the involved pointers are none that we allocated beforehand (we’ve tracked our Ruby allocations multiple times, and in no case did the pointers to our allocated values match the VALUE obj or klass pointers, we’re not even in a close range).

Any help would be appreciated—while it’s not 100% reliably reproducible, it can happen within a couple placements, and since it crashes Sketchup as a whole, it’s quite high impact.

I can provide minidumps with and without Heap if necessary.

Truncated callstack (Sketchup Pro 22.0.354, Windows 10):

x64-msvcrt-ruby270.dll!rb_class_of(unsigned __int64 obj) Line 2105 C
x64-msvcrt-ruby270.dll!rb_obj_respond_to(unsigned __int64 obj, unsigned __int64 id, int priv) Line 2184 C
SketchUp.exe!00007ff61eed4376() Unknown
SketchUp.exe!00007ff61ec0061f() Unknown
mfc140u.dll!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2699 C++

message is 0x00000201 (WM_LBUTTONDOWN)

Anyone with any infos or ideas how to drill into this further?

This is an issue for our customers and, as a crash bug, not something that’s easy to ignore either. I’d really appreciate some input or assistance.

Thanks a lot!

Are you or your customers getting BugSplat catching the crashes?
If so are they getting sent in and any crash numbers that can be looked up in the splat database?

Is your code 100% pure Ruby or are you also using the “live” C extension code ?

Is your code using Fiddle to make any Win32 API calls ?

Heya Dan,

Thanks for replying!

I just reproduced it again and submitted a bugsplat “Crash #652379”—the description contains a link to this forum thread, too.

We’re feeding a thin Ruby layer from C# (the main plugin codebase). Afaik all interactions with Sketchup are 100% through Ruby. We do not use Fiddle.



Oh, okay then you are wrapping “live” SketchUp C API calls in C# ?

You can file an issue in the official SketchUp API tracker at GitHub, but they will request reproducible code.
If it is proprietary @tt_su can give you an email addy to send it rather than post it publicly.

Thanks! Filed a bug report in the github bug tracker now.

We’re calling Ruby functions from C#, we don’t interact (directly) with C at all—I only have the C stacktraces since I tried to get to the bottom of the crash and that’s where it happened (and I had attached with native debugging).

Thanks for posting in the GitHub tracker. I see Thomas has responded. :+1:

Core Ruby functions or SketchUp API functions? FYI, Ruby itself is implemented in C.