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