"SystemStackError: stack level too deep" when invoking "Layout::SketchUpModel.new"

Hi,

I am encountering a problem when invoking Layout::SketchUpModel.new on several machine running under MacOS (but maybe it’s not OS dependant).

The error is SystemStackError: stack level too deep.

I’m sorry for the lack of informations because this doesn’t occurs on all computers with the same action and the same input model.

Does anyone encountering this kind of error when trying to add a SKP file to a newly created Layout file with Layout API ?

Boris,
The error you are seeing is coming from the Ruby kernel as opposed to the MacOS. Which suggests that there is some sort of recursion happening in the Ruby code. The example below demonstrates how to cause and catch the error. Perhaps you can insert a rescue clause in your code to gather some debugging info.

def self.loop()
  @i += 1
  loop()
end

@i = 1

begin
  loop()
rescue SystemStackError => e
  puts e.inspect
  puts e.backtrace.join("\n")
end
puts "Stack Depth #{@i}"
nil

2 Likes

Hi @sWilliams,

Thank you for this answer, but the stack trace pointed this line of code :

          skp = Layout::SketchUpModel.new(skp_path, Geom::Bounds2d.new(
            page_info.left_margin,
            current_y,
            page_info.width - page_info.left_margin - page_info.right_margin,
            page_info.height - current_y - page_info.bottom_margin
          ))

Then I’m not sure to be able to “control” the recursion loop if it comes from the Layout::SketchUpModel.new function …

Yes, I was suggesting, as a first guess, that the block of code containing the call to Layout::SketchUpModel.new is being called recursively. This would show up in the dump of the backtrace in the example code above which might contain tens of thousands of entries. If this is not the case then we need someone with knowledge of the implementation of the SketchUpModel.new method to offer some insight as to what might be wrong.

Out of curiosity I wrote a small Ruby C extension that intentionally contained a recursive function call and found that executing the code doesn’t throw a SystemStackError, it does eat up all of the system resources and cause Sketchup up to go a bit batty. Also, this is on a PC so a Mac might behave differently.

Skip

By curiosity, you can see the full ruby code here.

The strange thing is that this error doesn’t occur on the Mac I use to develop my extension. But it occurs each time this code is executed with all tested models on 2 other mac machines of tester users. It’s quit difficult to investigate, because I can’t see the problem on my dev machine.
I don’t know if it is specific to Mac, but no tester report this error on Windows.

Thinking about this one…
tough nut to crack

A short conversation about the diagnostic tools that are available in Ruby.

One question that I have is whether Layout::SketchUpModel.new is actually being called or has something gone terribly wrong in evaluating the arguments to that call. To answer this question on my own windows machine I’d start up x64dbg and attach to the Sketchup Process and set a break point on that function’s entry point. I don’t know if this is possible on the Mac platform. On both platform we can accomplish this by setting up a Ruby TracePoint that will report all of the calls into C routines. Below are a couple of examples to demonstrate the information that is available.

# https://ruby-doc.org/3.1.4/TracePoint.html
@limit = 0 # Protect ourselves from loops
trace1 = TracePoint.new(:c_call,:c_return) do |tp|
  tp.disable
  p [tp.lineno, tp.event, tp.inspect]
  @limit -= 1
  tp.enable if @limit > 0
end

@limit = 30
trace1.enable

  model = Sketchup.active_model()
  sel = model.selection

trace1.disable


# This is an example of what tracepoint will show when there is an argument error
puts " \nCall with wrong arguments example"
@limit = 0
trace2 = TracePoint.new(:c_call,:c_return) do |tp|
  tp.disable
  p [tp.lineno, tp.event, tp.inspect]
  @limit -= 1
  tp.enable if @limit > 0
end

@limit = 30
trace2.enable

  model = Sketchup.active_model("string")
  sel = model.selection

trace2.disable

Hi sWilliams,

Thanks for your investigations.

The main problem is that in most of case, it simply closes SketchUp with a bug splat. The SystemStackError occurs in rare case on this machine. And unfortunately this machine is not mine. Then it quite hard to debug on a user machine.

On all other machine I teste, it works without any problems.

Currently I add a begin / rescue and nothing change. SU simply crashes…

Ouch! Have any of the bugsplats been sent in with an identifying name/userID attached so we can ask Colin to look them up?

(hint) Your initial report in the first post does not mention OS version and SketchUp version for the machines on which it fails.


If the 2D bounds argument is valid to the viewport constructor, then I would think that there must be an error in the writing of the temp definition file.

I do see you check the return skp_success value, but do you check it against File.exist? ?

The API docs indicate that #save_copy should be used when silently saving definitions. I don’t know as this would cause any difference in the serialization of the file. (We would not think so.)

The API tracker has several bugs that were fixed recently that have to do with component save:

SketchUp/api-issue-tracker search “component save” Closed


Another thing I notice is that you are using SecureRandom to generate a UUID. Over the years there have been issues with this. I believe it uses OpenSSL which is constantly being updated to fix bugs.

Look at the API Release Notes and you’ll it has updated the distributed OpenSSL library at least 5 times in the past 3 major release cycles (from 1.1.1g to l to k to o to 1.1.1t).

The Sketchup::Definition class has a #guid method. Why not use this, by naming the new definition "temp#{Time.new.to_i}" then in the next statement rename it:
tmp_definition.name= tmp_definition.guid

Anyway, this last is just musing. I don’t think this has to do with the crash.

I can give you this @sWilliams :

Incident Identifier: DC9B3D47-2832-453B-9D52-A7F1ED8ED2EA
CrashReporter Key: A4AF8F9C-FF03-50C6-93E6-CD09F7879CAE

And as you can see the loop is visible in crash report …

Thread 0 Crashed:
0   libSketchUpViewerAPI.dylib           0x00000001259cc4cd 0x12574c000 + 2622669
1   libSketchUpViewerAPI.dylib           0x0000000125c4fb53 0x12574c000 + 5258067
2   libLayOutModel.dylib                 0x000000012544c246 0x125440000 + 49734
3   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
4   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
5   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
6   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
7   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
8   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
9   libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
10  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
11  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
12  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
13  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
14  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
15  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
16  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
17  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
18  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
19  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
20  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
21  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
22  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
23  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
24  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
25  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
26  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
27  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
28  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
29  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
30  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
31  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
32  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
33  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
34  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
35  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
36  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
37  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
38  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
39  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
40  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
41  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
42  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
43  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
44  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
45  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
46  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
47  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
48  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
49  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
50  libLayOutModel.dylib                 0x000000012544c38b 0x125440000 + 50059
...

Hi @DanRathbun,

This occur on a MacBookPro mi2014, MacOs BigSur 10.6.4 running Sketchup 2023.

I do see you check the return skp_success value, but do you check it against File.exist? ?

Right, I will add this test.

The API docs indicate that #save_copy should be used when silently saving definitions.

I will fix this, thanks !

As we can see, the temp SKP file is correctly generated.

The Sketchup::Definition class has a #guid method. Why not use this, by naming the new definition "temp#{Time.new.to_i}" then in the next statement rename it:
tmp_definition.name= tmp_definition.guid

Hmm, your right. I will take a look at that !

Thank you for your feedbacks.

1 Like

Thank you @DanRathbun for joining the hunt. Anyone else have an idea?

At this point let’s call in @colin to see what he can dig up with the dump data. He has a genius ability to find the critical details on problems like this.

If I’m correct this problem starts with a call to LOSketchUpModelCreate() from the LayoutRubyAPI.

1 Like

After the the last Release of OpenCutList 5.0, I can count one more Mac user for this issue

But this time his machine running on Mac OS X 10.15.7.
Always with the last SketchUp 2023.

Currently they all running Mac OS 10.x.

Where could be the best place to report it ?

Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libLayOutModel.dylib 0x000000011a9d31f0 layout::SkpModelRef::GetDefaultPage() + 18
1 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
2 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
3 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
4 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
5 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
6 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
7 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
8 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
9 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
10 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
11 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
12 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
13 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
14 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
15 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
16 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
17 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
18 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
19 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
20 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
21 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
22 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
23 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
24 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429
25 libLayOutModel.dylib 0x000000011a9d338b layout::SkpModelRef::GetDefaultPage() + 429

The official SketchUp API Issue tracker at GitHub.

1 Like