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 <[email protected]> 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 <[email protected]> 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/Y2CCRubyClient.h > > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClientComponent.h > > > > actual call of client > > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClientComponent.cc#L53 > > https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L237 > > > > 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. > -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
