RBA::QSpacerItem: potential use-after-free bug due to Ruby GC

[tskaar]

Hi!

When using the IHP PDK and opening up their DRC Options menu I saw a segfault happen at random times, after some trial-and-error I found the culprit to be RBA::QSpacerItem .

The file in question is this: https://github.com/IHP-GmbH/IHP-Open-PDK/blob/dev/ihp-sg13g2/libs.tech/klayout/tech/macros/sg13g2_drc_options.lym

Where the lines of interest are:

    ## --- Basic Settings Tab ---
    @spacer = RBA::QSpacerItem.new(0, 5) # <-- Initialized here
    @basic_tab = RBA::QWidget.new
    @basic_layout_setup = RBA::QFormLayout.new(@basic_tab)
    @basic_layout_setup.setSpacing(15)
    @basic_layout_setup.addRow("Top Cell:", create_combo_box(options['top_cell'], get_top_cell_names))
    @basic_layout_setup.addRow("Run Mode:", create_combo_box(options['run_mode'], ['deep', 'flat']))
    @basic_layout_setup.addRow("DRC Table:", create_combo_box(options['table'] || "main", get_table_files))
    @basic_layout_setup.addRow("Parallel Runs:", create_cores_threads_no(options['parallel_runs']))
    @basic_layout_setup.addItem(@spacer) # <-- Referenced here
    @basic_layout_setup.setSpacing(10)

Removing these two lines, also removes the segfault I've seen happen.

Considering there are multiple other ways of adding vertical space (that doesn't segfault), this is a very minor impact bug, but thought it would be "good to know" in case other people use QSpacerItem

Software

KLayout: v0.30.5
Qt: v6.10.2
Ruby: v3.4.8 +PRISM
Compiler: GCC: (GNU) 15.2.1 20251112
OS: ArchLinux

Additional information

Downstream bug report: IHP-GmbH/IHP-Open-PDK#815
That bug report also includes a video example of the trigger.

GDB backtrace: ihp_drc_options_segfault_backtrace.log

---

Let me know if you need any more information from me.

Thanks!

[klayoutmatthias]

Hi @tskaar,

thanks a lot for the analysis! You're perfectly right and if you got help by some LLM in that analysis, let me know. I need to establish some confidence in that technology on my side ...

Here is a short reproducer that I created myself without AI support:

10000.times do |i|
    
    puts "Iteration #{i} ..."
     
    spacer = RBA::QSpacerItem.new(0, 5)
    basic_tab = RBA::QWidget.new
    basic_layout_setup = RBA::QFormLayout.new(basic_tab)
    basic_layout_setup.setSpacing(15)

    basic_layout_setup.addItem(spacer)
    basic_layout_setup.setSpacing(10)
    
end

It crashes immediately.

I can add some more explanation: basically lifetime tracking is implemented in KLayout for QObject's, so if QLayoutItem was a QObject, that problem would not exists. But it is not.

Other kind of objects need to explicitly transfer ownership, as for the lack of the QObject base class shared ownership can't be implemented. Some methods automatically transfer ownership - for example "QFormLayout::addRow" does - but "QFormLayout::addItem" doesn't. That's a gap on my side. I will take care of adding the necessary features (the same needs to be supported for other QLayout variants and other methods) in the context of this ticket. I don't have test coverage for the whole Qt API, so more gaps of that kind are likely.

Fortunately there is a simple workaround for that case. By using an explicit call to "_unmanage", the ownership over the QSpacerItem object is transferred to the C++ side and Ruby will not try to call its destructor when the GC cleans up that object:

10000.times do |i|
    
    puts "Iteration #{i} ..."
     
    spacer = RBA::QSpacerItem.new(0, 5)
    basic_tab = RBA::QWidget.new
    basic_layout_setup = RBA::QFormLayout.new(basic_tab)
    basic_layout_setup.setSpacing(15)

    spacer._unmanage   # workaround for issue #2270

    basic_layout_setup.addItem(spacer)
    basic_layout_setup.setSpacing(10)
    
end

In my case I could no longer reproduce the issue that way.

Matthias

P.S: I'll keep the ticket open to remind me of including the "_unmanage" call into "addItem" by default, so you don't need to do that. If you find that workaround fixes the issue, you could do the IHP people a favor and drop them a note.

[tskaar]

Hi @klayoutmatthias!

Thanks for the detailed report, that makes sense!

thanks a lot for the analysis! You're perfectly right and if you got help by some LLM in that analysis, let me know. I need to establish some confidence in that technology on my side ...

I used an LLM to point me in the initial direction based on the backtrace that I got from GDB.
However when trying to generate a simple re-producer (like the one you attached) it focused on the wrong thing, so it was a bit hit & miss on that particular end. So, analysis wise it was decent, however for trying to fix/analyze the actual bug, it was a bit of a miss. For reference I used Google Gemini in this case.

Fortunately there is a simple workaround for that case. By using an explicit call to "_unmanage", the ownership over the QSpacerItem object is transferred to the C++ side and Ruby will not try to call its destructor when the GC cleans up that object:

Can confirm that this works around the bug as well, thanks!

If you find that workaround fixes the issue, you could do the IHP people a favor and drop them a note.

Yeah, I posted a PR already (IHP-GmbH/IHP-Open-PDK#816), but I'll re-factor it to use the explicit _unmanage and refer to this issue ticket instead, that's a better solution than temporarily commenting it out.

Thanks for the fast & detailed answer!