V Mon, 2 Oct 2017 10:48:46 -0600 David Mulder <[email protected]> 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 <[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]
