Here's a backtrace from the core dump: #0  0x00007f1b19bc12c7 in ?? () from /lib64/libgcc_s.so.1 #1  0x00007f1b19bc2e78 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1 #2  0x00007f1b2b679268 in backtrace () from /lib64/libc.so.6 #3  0x00007f1b185965e5 in ?? () from /usr/lib64/libruby2.2.so.2.2 #4  0x00007f1b1859681c in ?? () from /usr/lib64/libruby2.2.so.2.2 #5  0x00007f1b18472c4b in ?? () from /usr/lib64/libruby2.2.so.2.2 #6  0x00007f1b1852929e in ?? () from /usr/lib64/libruby2.2.so.2.2 #7  <signal handler called> #8  0x0000000000000060 in ?? () #9  0x00007f1b103d3c79 in QMetaObject::cast(QObject const*) const () from /usr/lib64/libQt5Core.so.5 #10 0x00007f1b111a1d8d in ?? () from /usr/lib64/libQt5Widgets.so.5 #11 0x00007f1b1115d276 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #12 0x00007f1b103cb578 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()    from /usr/lib64/libQt5Core.so.5 #13 0x00007f1b1041f5ae in QTimerInfoList::activateTimers() () from /usr/lib64/libQt5Core.so.5 #14 0x00007f1b1041fca1 in ?? () from /usr/lib64/libQt5Core.so.5 #15 0x00007f1b0ea9cb37 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #16 0x00007f1b0ea9cd68 in ?? () from /usr/lib64/libglib-2.0.so.0 #17 0x00007f1b0ea9cdfc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #18 0x00007f1b1042073f in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) ()    from /usr/lib64/libQt5Core.so.5 #19 0x00007f1b11e4571d in YQUI::idleLoop(int) () from /usr/lib64/yui/libyui-qt.so.8 #20 0x00007f1b1b1daadc in YUI::uiThreadMainLoop (this=0x558d3a611d60)     at /usr/src/debug/libyui-3.3.3/src/YUI.cc:357 #21 0x00007f1b1b1dac9e in start_ui_thread (yui=<optimized out>)     at /usr/src/debug/libyui-3.3.3/src/YUI.cc:493 #22 0x00007f1b2b92b4e7 in start_thread () from /lib64/libpthread.so.0 #23 0x00007f1b2b66ba2f in clone () from /lib64/libc.so.6 I'll try valgrinding it and send you the results. On 10/02/2017 09:51 AM, Josef Reidinger wrote:

V Mon, 2 Oct 2017 09:34:27 -0600 David Mulder napsáno:

...

I've written a yast module in python (can be found here: https://github.com/dmulder/yast-gpmc ), and have encountered some issues.

* When exiting the module, it always crashes, with a backtrace. It appears that yast is crashing in a destructor somewhere. <main>: [BUG] Segmentation fault at 0x000000000017f0 ruby 2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu]

-- Control frame information ----------------------------------------------- c:0001 p:0000 s:0002 E:0025e0 TOP    [FINISH]

-- Machine register context ------------------------------------------------ RIP: 0x00000000000017f0 RBP: 0x00007f69a34388c0 RSP: 0x00007f699f6b9a98 RAX: 0x00007f69983cff90 RBX: 0x00007f69980eb2a0 RCX: 0x00007f6998002e80 RDX: 0x00007f699f6b9cf0 RDI: 0x00007f69980eb2a0 RSI: 0x00007f69980eb2a0 R8: 0x00007f69984dadc8  R9: 0x00007f69984dada0 R10: 0x000055efbe7e7660 R11: 0x0000000000040614 R12: 0x00007f699f6b9cf0 R13: 0x00007f6998002150 R14: 0x00007f69980eb2a0 R15: 0x00007f699f6b9cf0 EFL: 0x0000000000010206

-- C level backtrace information ------------------------------------------- output is not much helpful, can you debug it with gdb and valgrind and print where it is badly accessed?

...

* Yast doesn't recognize python modules that are installed, and doesn't add them to the menu.

...

l /usr/local/share/YaST2/clients/gpmc.py -rw-r--r-- 1 root root 2057 Sep 28 09:03 /usr/local/share/YaST2/clients/gpmc.py sudo yast2 gpmc No such client module gpmc

It is known limitation of python bindings. Perl and python bindings does not have support for clients. Only ruby bindings have it and it was a bit tricky to add it. If you want to add it to python, check how ruby ones are done:

https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2CCRubyCl... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie...

actual call of client https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L...

so in short. You have to have Component creator for clients, then client component which do then actual call of python method that somehow invoke python code.

-- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Here are the results from valgrind: ==32174== Invalid read of size 8 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32174== ==32174== ==32174== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==32174==  Access not within mapped region at address 0x0 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  If you believe this happened as a result of a stack ==32174==  overflow in your program's main thread (unlikely but ==32174==  possible), you can try to increase the size of the ==32174==  main thread stack using the --main-stacksize= flag. ==32174==  The main thread stack size used in this run was 8388608. Full results are attached. On 10/02/2017 09:51 AM, Josef Reidinger wrote:

V Mon, 2 Oct 2017 09:34:27 -0600 David Mulder napsáno:

...

I've written a yast module in python (can be found here: https://github.com/dmulder/yast-gpmc ), and have encountered some issues.

* When exiting the module, it always crashes, with a backtrace. It appears that yast is crashing in a destructor somewhere. <main>: [BUG] Segmentation fault at 0x000000000017f0 ruby 2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu]

-- Control frame information ----------------------------------------------- c:0001 p:0000 s:0002 E:0025e0 TOP    [FINISH]

-- Machine register context ------------------------------------------------ RIP: 0x00000000000017f0 RBP: 0x00007f69a34388c0 RSP: 0x00007f699f6b9a98 RAX: 0x00007f69983cff90 RBX: 0x00007f69980eb2a0 RCX: 0x00007f6998002e80 RDX: 0x00007f699f6b9cf0 RDI: 0x00007f69980eb2a0 RSI: 0x00007f69980eb2a0 R8: 0x00007f69984dadc8  R9: 0x00007f69984dada0 R10: 0x000055efbe7e7660 R11: 0x0000000000040614 R12: 0x00007f699f6b9cf0 R13: 0x00007f6998002150 R14: 0x00007f69980eb2a0 R15: 0x00007f699f6b9cf0 EFL: 0x0000000000010206

-- C level backtrace information ------------------------------------------- output is not much helpful, can you debug it with gdb and valgrind and print where it is badly accessed?

...

* Yast doesn't recognize python modules that are installed, and doesn't add them to the menu.

...

l /usr/local/share/YaST2/clients/gpmc.py -rw-r--r-- 1 root root 2057 Sep 28 09:03 /usr/local/share/YaST2/clients/gpmc.py sudo yast2 gpmc No such client module gpmc

It is known limitation of python bindings. Perl and python bindings does not have support for clients. Only ruby bindings have it and it was a bit tricky to add it. If you want to add it to python, check how ruby ones are done:

https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2CCRubyCl... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie...

actual call of client https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L...

so in short. You have to have Component creator for clients, then client component which do then actual call of python method that somehow invoke python code.

-- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

What ruby-debug packages did you want installed? I'm not familiar with ruby or it's packaging. I see a 'debuginfo' package, but it's only available for ruby2.4+ On 10/02/2017 10:08 AM, Josef Reidinger wrote:

This stack looks like zero pointer access which is quite strange. Can you install ruby-debug packages, to get some defaults? Ideally it have to debugged by gdb to see what is going wrong.

Josef

V Mon, 2 Oct 2017 10:03:58 -0600 David Mulder napsáno:

...

Here are the results from valgrind:

==32174== Invalid read of size 8 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32174== ==32174== ==32174== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==32174==  Access not within mapped region at address 0x0 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  If you believe this happened as a result of a stack ==32174==  overflow in your program's main thread (unlikely but ==32174==  possible), you can try to increase the size of the ==32174==  main thread stack using the --main-stacksize= flag. ==32174==  The main thread stack size used in this run was 8388608.

Full results are attached.

On 10/02/2017 09:51 AM, Josef Reidinger wrote:

...

V Mon, 2 Oct 2017 09:34:27 -0600 David Mulder napsáno:

...

I've written a yast module in python (can be found here: https://github.com/dmulder/yast-gpmc ), and have encountered some issues.

* When exiting the module, it always crashes, with a backtrace. It appears that yast is crashing in a destructor somewhere. <main>: [BUG] Segmentation fault at 0x000000000017f0 ruby 2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu]

-- Control frame information ----------------------------------------------- c:0001 p:0000 s:0002 E:0025e0 TOP    [FINISH]

-- Machine register context ------------------------------------------------ RIP: 0x00000000000017f0 RBP: 0x00007f69a34388c0 RSP: 0x00007f699f6b9a98 RAX: 0x00007f69983cff90 RBX: 0x00007f69980eb2a0 RCX: 0x00007f6998002e80 RDX: 0x00007f699f6b9cf0 RDI: 0x00007f69980eb2a0 RSI: 0x00007f69980eb2a0 R8: 0x00007f69984dadc8  R9: 0x00007f69984dada0 R10: 0x000055efbe7e7660 R11: 0x0000000000040614 R12: 0x00007f699f6b9cf0 R13: 0x00007f6998002150 R14: 0x00007f69980eb2a0 R15: 0x00007f699f6b9cf0 EFL: 0x0000000000010206

-- C level backtrace information ------------------------------------------- output is not much helpful, can you debug it with gdb and valgrind and print where it is badly accessed?

...

* Yast doesn't recognize python modules that are installed, and doesn't add them to the menu.

...

l /usr/local/share/YaST2/clients/gpmc.py -rw-r--r-- 1 root root 2057 Sep 28 09:03 /usr/local/share/YaST2/clients/gpmc.py sudo yast2 gpmc No such client module gpmc

It is known limitation of python bindings. Perl and python bindings does not have support for clients. Only ruby bindings have it and it was a bit tricky to add it. If you want to add it to python, check how ruby ones are done:

https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2CCRubyCl... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie...

actual call of client https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L...

so in short. You have to have Component creator for clients, then client component which do then actual call of python method that somehow invoke python code.

-- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Since the python bindings were very broken, and being deprecated... https://github.com/dmulder/yast-python-bindings2 I wrote new python bindings. They still need some work, but they're able to run my yast python modules now. The crash at shutdown is gone, and I now get extensive debug when something goes wrong. Much better! These bindings are generated using SWIG, plus there's some wrapper functions to simplify things on the python side. Suggestions? Feedback? On 10/03/2017 01:31 AM, Josef Reidinger wrote:

V Mon, 2 Oct 2017 10:48:46 -0600 David Mulder napsáno:

...

What ruby-debug packages did you want installed? I'm not familiar with ruby or it's packaging. I see a 'debuginfo' package, but it's only available for ruby2.4+ It depends what system ruby you use. but it looks like it use ruby2.2 then package is libruby2_2-2_2-debuginfo

Josef

...

On 10/02/2017 10:08 AM, Josef Reidinger wrote:

...

This stack looks like zero pointer access which is quite strange. Can you install ruby-debug packages, to get some defaults? Ideally it have to debugged by gdb to see what is going wrong.

Josef

V Mon, 2 Oct 2017 10:03:58 -0600 David Mulder napsáno:

...

Here are the results from valgrind:

==32174== Invalid read of size 8 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32174== ==32174== ==32174== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==32174==  Access not within mapped region at address 0x0 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  If you believe this happened as a result of a stack ==32174==  overflow in your program's main thread (unlikely but ==32174==  possible), you can try to increase the size of the ==32174==  main thread stack using the --main-stacksize= flag. ==32174==  The main thread stack size used in this run was 8388608.

Full results are attached.

On 10/02/2017 09:51 AM, Josef Reidinger wrote:

...

V Mon, 2 Oct 2017 09:34:27 -0600 David Mulder napsáno:

...

I've written a yast module in python (can be found here: https://github.com/dmulder/yast-gpmc ), and have encountered some issues.

* When exiting the module, it always crashes, with a backtrace. It appears that yast is crashing in a destructor somewhere. <main>: [BUG] Segmentation fault at 0x000000000017f0 ruby 2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu]

-- Control frame information ----------------------------------------------- c:0001 p:0000 s:0002 E:0025e0 TOP    [FINISH]

-- Machine register context ------------------------------------------------ RIP: 0x00000000000017f0 RBP: 0x00007f69a34388c0 RSP: 0x00007f699f6b9a98 RAX: 0x00007f69983cff90 RBX: 0x00007f69980eb2a0 RCX: 0x00007f6998002e80 RDX: 0x00007f699f6b9cf0 RDI: 0x00007f69980eb2a0 RSI: 0x00007f69980eb2a0 R8: 0x00007f69984dadc8  R9: 0x00007f69984dada0 R10: 0x000055efbe7e7660 R11: 0x0000000000040614 R12: 0x00007f699f6b9cf0 R13: 0x00007f6998002150 R14: 0x00007f69980eb2a0 R15: 0x00007f699f6b9cf0 EFL: 0x0000000000010206

-- C level backtrace information ------------------------------------------- output is not much helpful, can you debug it with gdb and valgrind and print where it is badly accessed?

...

* Yast doesn't recognize python modules that are installed, and doesn't add them to the menu. > l /usr/local/share/YaST2/clients/gpmc.py -rw-r--r-- 1 root root 2057 Sep 28 09:03 /usr/local/share/YaST2/clients/gpmc.py > sudo yast2 gpmc No such client module gpmc

It is known limitation of python bindings. Perl and python bindings does not have support for clients. Only ruby bindings have it and it was a bit tricky to add it. If you want to add it to python, check how ruby ones are done:

https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2CCRubyCl... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie...

actual call of client https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie... https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L...

so in short. You have to have Component creator for clients, then client component which do then actual call of python method that somehow invoke python code.

-- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Hi, few notes:

1. whole UI related stuff should be done using common import + UI.call as it is already attached to component system and it is not written in ruby. What is this common import and UI.call? I don't follow.

2. yast.py is basically reimplementation of yast stuff in python. I am not sure if it is right way, as anything you will need you have to reimplement Yes, the yast.py code is wrong. I'm trying to think of a good way to use

the ruby Wizard code, etc. You mention there is a way to be able to call functions between yast modules?

3. your modules is not possible to call from rest of YaST. For ycp, perl and ruby it is possible to call it from each other.

So in short. Your approach is more like wrapper for c++ parts ( currently only UI ) and rewrite for rest.

In general if you need only UI from YaST, then I suggest to use direct approach and use libyui python bindings - https://github.com/libyui/libyui-bindings . But as I said this approach prevent you to use any part written in ruby and also rest of YaST cannot call your methods.

It miss some layer from ycp-ui-bindings, but provide all needed to build UI.

Josef

...

On 10/03/2017 01:31 AM, Josef Reidinger wrote:

...

V Mon, 2 Oct 2017 10:48:46 -0600 David Mulder napsáno:

...

What ruby-debug packages did you want installed? I'm not familiar with ruby or it's packaging. I see a 'debuginfo' package, but it's only available for ruby2.4+ It depends what system ruby you use. but it looks like it use ruby2.2 then package is libruby2_2-2_2-debuginfo

Josef

...

On 10/02/2017 10:08 AM, Josef Reidinger wrote:

...

This stack looks like zero pointer access which is quite strange. Can you install ruby-debug packages, to get some defaults? Ideally it have to debugged by gdb to see what is going wrong.

Josef

V Mon, 2 Oct 2017 10:03:58 -0600 David Mulder napsáno:

...

Here are the results from valgrind:

==32174== Invalid read of size 8 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174== by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174== by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174== by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32174== ==32174== ==32174== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==32174==  Access not within mapped region at address 0x0 ==32174==    at 0x18E99855: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174== by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174==    by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) ==32174==    by 0x231AA140: QAbstractEventDispatcherPrivate::allocateTimerId() (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231AA7B8: QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x231DC54D: QObject::startTimer(int, Qt::TimerType) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==    by 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174== by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174== by 0x2AF5B8D1: dbus_connection_send_with_reply (in /lib64/libdbus-1.so.3.14.11) ==32174==    by 0x287C553C: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174==    by 0x231DAF61: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174==  If you believe this happened as a result of a stack ==32174==  overflow in your program's main thread (unlikely but ==32174==  possible), you can try to increase the size of the ==32174==  main thread stack using the --main-stacksize= flag. ==32174==  The main thread stack size used in this run was 8388608.

Full results are attached.

On 10/02/2017 09:51 AM, Josef Reidinger wrote: > V Mon, 2 Oct 2017 09:34:27 -0600 > David Mulder napsáno: > >> I've written a yast module in python (can be found here: >> https://github.com/dmulder/yast-gpmc ), and have encountered >> some issues. >> >> * When exiting the module, it always crashes, with a backtrace. >> It appears that yast is crashing in a destructor somewhere. >> <main>: [BUG] Segmentation fault at 0x000000000017f0 >> ruby 2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu] >> >> -- Control frame information >> ----------------------------------------------- c:0001 p:0000 >> s:0002 E:0025e0 TOP    [FINISH] >> >> >> -- Machine register context >> ------------------------------------------------ RIP: >> 0x00000000000017f0 RBP: 0x00007f69a34388c0 RSP: >> 0x00007f699f6b9a98 RAX: 0x00007f69983cff90 RBX: >> 0x00007f69980eb2a0 RCX: 0x00007f6998002e80 RDX: >> 0x00007f699f6b9cf0 RDI: 0x00007f69980eb2a0 RSI: >> 0x00007f69980eb2a0 R8: 0x00007f69984dadc8  R9: >> 0x00007f69984dada0 R10: 0x000055efbe7e7660 R11: >> 0x0000000000040614 R12: 0x00007f699f6b9cf0 R13: >> 0x00007f6998002150 R14: 0x00007f69980eb2a0 R15: >> 0x00007f699f6b9cf0 EFL: 0x0000000000010206 >> >> -- C level backtrace information >> ------------------------------------------- > output is not much helpful, can you debug it with gdb and > valgrind and print where it is badly accessed? > >> * Yast doesn't recognize python modules that are installed, and >> doesn't add them to the menu. >>> l /usr/local/share/YaST2/clients/gpmc.py >> -rw-r--r-- 1 root root 2057 Sep 28 09:03 >> /usr/local/share/YaST2/clients/gpmc.py >>> sudo yast2 gpmc >> No such client module gpmc >> > It is known limitation of python bindings. Perl and python > bindings does not have support for clients. Only ruby bindings > have it and it was a bit tricky to add it. > If you want to add it to python, check how ruby ones are done: > > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2CCRubyCl... > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie... > > actual call of client > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClie... > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L... > > so in short. You have to have Component creator for clients, > then client component which do then actual call of python > method that somehow invoke python code.

-- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Problem is that you do not use Yast component system. In general all yast modules is attached to component system and you can call it with it. Old python bindings implement it properly with

https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc I added in use of the yast component system, for calling into the Wizard class in the ruby code (branch ruby_bind on the same project). This works, but there is now blatant stack corruption (crashing, UI artifacts, etc). Here is the crash at shutdown:

#0  0x00007f7a704ad855 in ?? () from /usr/lib64/libruby2.2.so.2.2 #1  0x00007f7a70389c4b in ?? () from /usr/lib64/libruby2.2.so.2.2 #2  0x00007f7a7044029e in ?? () from /usr/lib64/libruby2.2.so.2.2 #3  <signal handler called> #4  0x0000000000000000 in ?? () #5  0x00007f7a732e3643 in YUIComponent::result(YCPValue const&) ()    from /usr/lib64/YaST2/plugin/libpy2UI.so.2 #6  0x00007f7a6c58b4f0 in ?? () from /usr/lib64/ruby/vendor_ruby/2.2.0/x86_64-linux-gnu/yastx.so #7  0x00007f7a70496b4d in ?? () from /usr/lib64/libruby2.2.so.2.2 #8  0x00007f7a704a78ce in ?? () from /usr/lib64/libruby2.2.so.2.2 #9  0x00007f7a7049b3eb in ?? () from /usr/lib64/libruby2.2.so.2.2 #10 0x00007f7a704a1224 in ?? () from /usr/lib64/libruby2.2.so.2.2 #11 0x00007f7a704a5ffc in ?? () from /usr/lib64/libruby2.2.so.2.2 #12 0x00007f7a704a6323 in ?? () from /usr/lib64/libruby2.2.so.2.2 #13 0x00007f7a704a63f8 in ?? () from /usr/lib64/libruby2.2.so.2.2 #14 0x00007f7a7039573c in ?? () from /usr/lib64/libruby2.2.so.2.2 #15 0x00007f7a704a27e3 in ?? () from /usr/lib64/libruby2.2.so.2.2 #16 0x00007f7a704a3a92 in ?? () from /usr/lib64/libruby2.2.so.2.2 #17 0x00007f7a704a8bf0 in rb_eval_cmd () from /usr/lib64/libruby2.2.so.2.2 #18 0x00007f7a703a0003 in ?? () from /usr/lib64/libruby2.2.so.2.2 #19 0x00007f7a7038f55d in rb_protect () from /usr/lib64/libruby2.2.so.2.2 #20 0x00007f7a703a1376 in ?? () from /usr/lib64/libruby2.2.so.2.2 #21 0x00007f7a703ab3d4 in rb_gc_call_finalizer_at_exit () from /usr/lib64/libruby2.2.so.2.2 #22 0x00007f7a709bb80d in YRuby::~YRuby() () from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so #23 0x00007f7a709bb8ee in YRuby::destroy() () from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so #24 0x00007f7a709b66cd in Y2RubyComponent::~Y2RubyComponent() ()    from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so #25 0x00007f7a709b67c9 in Y2RubyComponent::~Y2RubyComponent() ()    from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so #26 0x00007f7a709b5aa1 in Y2CCRuby::~Y2CCRuby() () from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so #27 0x00007f7a84b4e638 in __run_exit_handlers () from /lib64/libc.so.6 #28 0x00007f7a84b4e68a in exit () from /lib64/libc.so.6 #29 0x00007f7a84b37471 in __libc_start_main () from /lib64/libc.so.6 #30 0x000055950bf6c7fa in _start () Any thoughts?

which adds to python ability to call rest of component system. import is finding module like

https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc#L107

and call it with

https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc#L1238

so to call UI methods you need to import module "UI" and then with that call use method you want from UI namespace.

...

...

2. yast.py is basically reimplementation of yast stuff in python. I am not sure if it is right way, as anything you will need you have to reimplement Yes, the yast.py code is wrong. I'm trying to think of a good way to use the ruby Wizard code, etc. You mention there is a way to be able to call functions between yast modules? yes, as I describe above.

...

...

3. your modules is not possible to call from rest of YaST. For ycp, perl and ruby it is possible to call it from each other.

So in short. Your approach is more like wrapper for c++ parts ( currently only UI ) and rewrite for rest.

In general if you need only UI from YaST, then I suggest to use direct approach and use libyui python bindings - https://github.com/libyui/libyui-bindings . But as I said this approach prevent you to use any part written in ruby and also rest of YaST cannot call your methods.

It miss some layer from ycp-ui-bindings, but provide all needed to build UI.

Josef

-- David Mulder SUSE Labs Software Engineer - Samba dmulder@suse.com SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 10/06/2017 03:29 PM, David Mulder wrote:

...

Hi, few notes:

1. whole UI related stuff should be done using common import + UI.call as it is already attached to component system and it is not written in ruby. What is this common import and UI.call? I don't follow.

Maybe reading this helps http://yastgithubio.readthedocs.io/en/latest/architecture/ Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org