SU25 Crashes when running long-duration ruby extension

I’m in the process of making sure my extensions work with the latest version of Sketchup (SU25), and I have found that one of them consistently crashes.

I have an extension that has a “batch” mode, where it opens all the SU files in a folder one at a time, and appends a page (with a few viewports) to a LO document for each SU file. I originally wrote this because appending the pages one at time became too slow as the LO file got larger. Doing it in batch mode, I don’t have to open, modify, and save the LO file each time.

I did have problems with this crashing in SU24, but by forcing the ruby console window to be open, it would reliably run to completion (albeit quite a bit slower). Now, even with the ruby console window open, I can do approximately 10 files before SU silently closes.

I’m kind of at a loss here. Without a bugsplat, what clues do I have to help me find out why it’s crashing?

I believe this can be related issue:

Oh, yes! That seems quite similar. Relief that I’m not alone on this.

However, I am able to create a LO doc and add a single page. Or append a single page to an existing LO doc. SU does not crash if I don’t use the “batch” mode.

I get a similar issue with SU2025, that is, a slient crash of Sketchup, in relation with changing the current model in the Sketchup session. It even crashes Layout silently 40s seconds later.

I reported this to Trimble along with a video.

Thanks for that, Fredo. In your case, you were not even using the Ruby API?

This is interesting. Usually, crash after running for a long time indicates that some vital resource was used up, such as system memory, stack, etc. What did the crash report say?

Unfortunately the SILENT crash does not say anything!
You can see more, for example an example code to reproduce, in the topic I linked in a second post above.

I get a lot of those silent crashes 24 and 25 when I have layout open, refreshing a model, but have 1-2-3 other models open.

Not sure how useful this is, but here’s the Windows event log:

Faulting application name: SketchUp.exe, version: 25.0.0.0, time stamp: 0x67b4eeed
Faulting module name: ntdll.dll, version: 10.0.26100.3037, time stamp: 0x95e6c489
Exception code: 0xc0000374
Fault offset: 0x000000000008b035
Faulting process id: 0x5570
Faulting application start time: 0x1DB8DF301D2BFEF
Faulting application path: C:\Program Files\SketchUp\SketchUp 2025\SketchUp\SketchUp.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 670cb8a4-4087-463d-995a-8e397a149be5
Faulting package full name: 
Faulting package-relative application ID: 

Exception code and Fault Offset are always the same every time it crashes.

1 Like

I don’t know much about how Windows captures crash info, only that on Mac there is a crash report logged even for a silent crash that doesn’t result in a BugSplat. Without inside knowledge of the source code you can’t tell a lot, but a knowledgable person can find out why the crash occurred.

Actually, this is in relation with the Layout API from a live Sketchup session. In my case, the Layout is fully created by API. The crash does not happen if you close everything, and then reopen the model and the Layout document.

By the way, here is how the Layout is produced and how models are switched in the Sketchup session via the API.

My situation is similar in that regard. The LO document is being fully created from SU using the ruby API.

This is heap corruption. I always reboot after memory errors.

I was not able to get the silent crash until I explicitly ran garbage collection via GC.start at the console.

So, where to now? How do we bring this to Trimble’s attention? I’m kind of stuck. My users and I can’t upgrade until this is fixed.

I opened a Labs report that is separate from Fredo’s previous report and referenced the two topics here in the forum. We can only wait for Kalpana, @tt_su or @bugra to respond.

Thanks, @DanRathbun.

1 Like