Crashing when reading files via Ruby

[thomthom]

Do you have a sample file? (And just to be sure we're not interpreting any hidden context differently, small snippet?)

File here: blowup.zip

When attempting to load locally, I've tried with all extensions disabled (and with them enabled), and I made sure that I could open the model in SketchUp itself. It was in my ~/Documents dir and I checked that macOS has permissions set for SketchUp to access my Documents directory.

path = File.join(File.expand_path('~'), 'Documents', 'blowup.skp')
File.exists?(path) # true
File.readable?(path) # true
file = File.open(path) # also fails when using modes 'r' and 'rb'
file.read # blows up here

If you do, did you submit with any information into the input fields we can use to look it up?

Submitted a Bugsplat around 8AM Eastern today. Used sasmithjr as the name field. Incident id listed as B474B71F-1E24-4C03-893A-F3DDE2D5DA50 in the details, and the Bugsplat webpage says references Crash #214495. If there's other info I can provide that'd make lookup easier, let me know. It's super easy to cause a crash so I can quickly get you another bugsplat lol

I see a regression between SU2021.0 and SU2021.1

Correct. I should have made the fact that this is a regression more prominent. I'm sorry about that! It also worked in SU2020, but I don't have the exact versions recorded.

I'm escalating this internally. You might want to hold off doing any major refactoring because of this. We might be needing a patch release that will mitigate the impact of this.

👍 I'll hold off for now then. Thank you!

Originally posted by @sasmithjr in https://github.com/SketchUp/api-issue-tracker/issues/646#issuecomment-863193735

[thomthom]

You see this on macOS only?

What version of macOS are you using?

Have you tried different SU versions?

[thomthom]

Internal note: BugSplat report 214495

[thomthom]

Is this happening only when done from the Ruby Console?

Looking at the call stack I wonder if it relates to text handling, where maybe we have an issue with binary data...

[sasmithjr]

You see this on macOS only?

I only have macOS to test with currently.

What version of macOS are you using?

macOS 11.4

Have you tried different SU versions?

Both 21.0.338 and 21.1.278 exhibit this behavior.

Is this happening only when done from the Ruby Console?

It would seem so. I hadn't tested via a loaded plugin yet. It correctly executes the following ruby file when placed in the Plugins dir:

file = File.open(File.join(File.expand_path('~'), 'Documents', 'blowup.skp'))
puts "Size: #{file.size}"
contents = file.read
puts "Contents length: #{contents.length}"
puts "Contents[100]: #{contents[100]}"

So it would seem this is an issue only when reading via Ruby Console. That's a relief.

[thomthom]

Ok, so that mitigates the impact for release. But still a pain for developers tinkering.

[DanRathbun]

(Moved from the previous issue ...)

@sasmithjr : When attempting to load locally, I've tried with all extensions disabled (and with them enabled), and I made sure that I could open the model in SketchUp itself. It was in my ~/Documents dir and I checked that macOS has permissions set for SketchUp to access my Documents directory.

Just a note that it is best practice to wrap any IO operations in a begin ... rescue clause. (Note I did this in the issue 646 examples.)

FTR, ... on Windows 10 (running SU v21.1.279) I get no error with the following, pasted into and run from the console:

def issue_649_file_read(filename = 'test.skp')
  path = File.join(File.expand_path('~'), 'Documents', filename)
  puts "path exists? #{File.exists?(path)}"
  puts "file readable? #{File.readable?(path)}"
  begin
    file = File.open(path, 'rb')
    puts "File inspection: #{file.inspect}"
    data = file.read # blows up here on MacOS ?
  rescue => err
    puts "File IO Error:"
    puts err.inspect
  else
    puts "File read successful. (length: #{data.size})"
  ensure
    file.close
  end
end ###

~

[sketchupbot]

Logged as: SKEXT-3113

[kalpana-ghodeswar]

Hi sasmithjr

This issue has been resolved as part of some other fix. I am not able to reproduce this in SU2023.0 SU2024.0 and SU2025.0 . Is this still an issue for you?

Thanks