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 <[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. -- David Mulder SUSE Labs Software Engineer - Samba [email protected] SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
