Backtrace open qt ui files

For release 0.24.10 I create some qt designer ui files.
Interacting with the same ui files (created by qt4 designer) causes a backtrack (dialog.destroy()) or allocation issue.
I tried python 3.6 and 2.7 using QT4.8.6.

------ small program to load the ui files:

from pya import *
import sys
import types
from os.path import curdir, join

def bexit(self):
      print("cancel")
     dialog.destroy()


def button(self):
     print("ok")
     dialog.destroy()
    
#dialog = QDialog(pya.Application.instance().main_window())
#dialog.windowTitle = "Generate PolygonBox"
#layout = QVBoxLayout.new(dialog)
#dialog.setLayout(layout)

# read the GUI from qt designer
ui_path = join("/home/parallels/klayout_dot/pymacros", "test.ui") 
ui_file = pya.QFile(ui_path)

parent = pya.Application.instance().main_window()
ui_file.open(pya.QIODevice.ReadOnly)
dialog = pya.QFormBuilder().load(ui_file, parent)
ui_file.close()

dialog.ok.clicked(button)
dialog.cancel.clicked(bexit)

#dialog.exec_()
dialog.show()

----- backtrace click on cancel:
Signal number: 11
Address: 0x29
Program Version: KLayout 0.25 (2017-11-12 r20a6c5e)

Backtrace:
/usr/lib64/klayout/libklayout_lay.so.0 +0x27c1b0 ?? [??:0]
/lib64/libpthread.so.0 +0xf100 __restore_rt [sigaction.c:?]
/lib64/libpython2.7.so.1.0 +0xab639 ?? [??:0]
/usr/lib64/klayout/libklayout_pya.so.0 +0x69918 ?? [??:0]
/usr/lib64/klayout/libklayout_pya.so.0 +0x69b93 ?? [??:0]
/usr/lib64/klayout/libklayout_gsiqt.so.0 +0xd53aae ?? [??:0]
/lib64/libQtCore.so.4 +0x1986c4 ?? [??:0]
/lib64/libQtGui.so.4 +0x849172 ?? [??:0]
/lib64/libQtGui.so.4 +0x58dd13 ?? [??:0]
/lib64/libQtGui.so.4 +0x58f0c7 ?? [??:0]
/lib64/libQtGui.so.4 +0x58f1cc ?? [??:0]
/lib64/libQtGui.so.4 +0x21bb18 ?? [??:0]
/lib64/libQtGui.so.4 +0x1c8d3c ?? [??:0]
/lib64/libQtGui.so.4 +0x1cf799 ?? [??:0]
/usr/lib64/klayout/libklayout_lay.so.0 +0xd7f06 ?? [??:0]
/lib64/libQtCore.so.4 +0x183b2d ?? [??:0]
/lib64/libQtGui.so.4 +0x1ceec7 ?? [??:0]
/lib64/libQtGui.so.4 +0x24456b ?? [??:0]
/lib64/libQtGui.so.4 +0x242fdc ?? [??:0]
/lib64/libQtGui.so.4 +0x26a9a4 ?? [??:0]
/lib64/libglib-2.0.so.0 +0x497aa ?? [??:0]
/lib64/libglib-2.0.so.0 +0x49af8 ?? [??:0]
/lib64/libglib-2.0.so.0 +0x49bac ?? [??:0]
/lib64/libQtCore.so.4 +0x1b25d5 ?? [??:0]
/lib64/libQtGui.so.4 +0x26ab26 ?? [??:0]
/lib64/libQtCore.so.4 +0x18265f ?? [??:0]
/lib64/libQtCore.so.4 +0x1829ad ?? [??:0]
/lib64/libQtCore.so.4 +0x187eb9 ?? [??:0]
/usr/lib64/klayout/libklayout_lay.so.0 +0xcf8d3 ?? [??:0]
/usr/lib64/klayout/libklayout_lay.so.0 +0xd87c0 ?? [??:0]
klayout +0x286a
/usr/lib64/klayout/libklayout_rba.so.0 +0x1adc8
/lib64/libruby.so.2.0 +0x163672
/lib64/libruby.so.2.0 +0x17505e
/lib64/libruby.so.2.0 +0x168a0c
/lib64/libruby.so.2.0 +0x16dbaf
/lib64/libruby.so.2.0 +0x16fc3f rb_iseq_eval_main
/lib64/libruby.so.2.0 +0x67fda
/lib64/libruby.so.2.0 +0x696ed ruby_exec_node
/lib64/libruby.so.2.0 +0x6b22e ruby_run_node
/usr/lib64/klayout/libklayout_rba.so.0 +0x1b2c4 _ZN3rba15RubyInterpreter10initializeEiPPcPFiiS2_E
klayout +0x21f3
/lib64/libc.so.6 +0x21b15 __libc_start_main
klayout +0x23c6

In case I comment out to destroy the GUI I receive:
Caught the following exception:
std::bad_alloc in Region.insert (Class exceptions.RuntimeError)

The same program runs fine in 0.24.10 with the same Release of QT and python.
I regenerate another qt designer ui file to exclude an issue with qt.
In case I define the button during the runtime without the ui file it works fine.

Best Regards,
Andy

[klayoutmatthias]

Hi Andy,

The problem is not related to the way the dialog is produced. In fact, the root cause is the "destroy" call. "destroy" will delete the Qt object and is equivalent to C++ "delete". But while this is done, the event handler is still active and destroying the object in that phase basically means digging your own grave. The effect is undefined and it's very difficult to predict when this will work. 0.25 has been significantly enhanced over 0.24.10 in that area. That will explain the effect.

I can try to harden the code against such behaviour, but the solution preferred by Qt is to use "deleteLater":

def bexit(self):
     print("cancel")
     dialog.deleteLater()
...

"deleteLater" defers the delete until it's safe to do so.

Another solution is to configure the Dialog as "deleteOnClose" (setting Qt::WA_DeleteOnClose for the windows flags) and do a "hide" in the event handler instead of a "delete".

Matthias