[Discuss-gnuradio] gr_modtool segfault at shutdown [thrift]

[Nicolas Cuervo Benavides]

Hey all,

I've noticed that gr_modtool eventually segfaults on shutdown while running 'newmod' and/or 'add' (with the other options it may come up, but I don't use them as often and I also don't have a way to consistently replicate this behavior).

I ran a backtrace, in this case for 'gr_modtool add' and got the following :

(gdb) run ~/src/prefix/bin/gr_modtool add seg -t sync -l cpp
Starting program: /usr/bin/python ~/src/prefix/bin/gr_modtool add seg -t sync -l cpp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1bd3700 (LWP 13889)]
[New Thread 0x7ffff1ad2700 (LWP 13890)]
[New Thread 0x7ffff19d1700 (LWP 13891)]
[New Thread 0x7ffff18d0700 (LWP 13892)]
[New Thread 0x7ffff17cf700 (LWP 13893)]
[New Thread 0x7ffff16ce700 (LWP 13894)]
[New Thread 0x7ffff15cd700 (LWP 13895)]
[New Thread 0x7ffff14cc700 (LWP 13896)]
[New Thread 0x7ffff13cb700 (LWP 13897)]
[New Thread 0x7ffff12ca700 (LWP 13898)]
GNU Radio module name identified: s
Language: C++
Block/code identifier: seg
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n]
Add C++ QA code? [y/N]
Adding file 'lib/seg_impl.h'...
Adding file 'lib/seg_impl.cc'...
Adding file 'include/s/seg.h'...
Editing swig/s_swig.i...
Adding file 'python/qa_seg.py'...
Editing python/CMakeLists.txt...
Adding file 'grc/s_seg.xml'...
Editing grc/CMakeLists.txt...
[Thread 0x7ffff13cb700 (LWP 13897) exited]
[Thread 0x7ffff17cf700 (LWP 13893) exited]
[Thread 0x7ffff12ca700 (LWP 13898) exited]
[Thread 0x7ffff18d0700 (LWP 13892) exited]
[Thread 0x7ffff19d1700 (LWP 13891) exited]
[Thread 0x7ffff1bd3700 (LWP 13889) exited]
[Thread 0x7ffff15cd700 (LWP 13895) exited]
[Thread 0x7ffff14cc700 (LWP 13896) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1ad2700 (LWP 13890)]
0x0000000000b822c0 in ?? ()
(gdb) bt
#0  0x0000000000b822c0 in ?? ()
#1  0x00007ffff294e14d in apache::thrift::concurrency::Guard::~Guard() ()
   from /home/user/src/prefix/lib/libthrift-0.9.3.so
#2  0x00007ffff2953078 in apache::thrift::concurrency::Synchronized::~Synchronized() ()
   from /home/user/src/prefix/lib/libthrift-0.9.3.so
#3  0x00007ffff2953a52 in apache::thrift::concurrency::ThreadManager::Worker::run() ()
   from /home/user/src/prefix/lib/libthrift-0.9.3.so
#4  0x00007ffff2993e6b in apache::thrift::concurrency::PthreadThread::threadMain(void*)
    () from /home/user/src/prefix/lib/libthrift-0.9.3.so
#5  0x00007ffff7bc4184 in start_thread (arg=0x7ffff1ad2700) at pthread_create.c:312
#6  0x00007ffff78f137d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

When I catch the segfault with 'newmod', the backtrace shows the same output. This segfault does not seem to affect functionality.

I went to read the ControlPort page, and saw that the this bt output is different to the one written at [1], and there it is encouraged to post it the differences on the list (reason why I'm reaching you all right now). As it is different, I have a bunch of questions that pop into my head:

1. it is maybe the same old-known issue with different phrasing? I'm not familiar with thrift and definitely the code has changed on the *server.* files where the guard was added as part of the proposed patch from [1]. The differences on the output may have resulted from the implementation of the code on thrift for the release we are using.

2. Given that is not the same output, It may be not worth it to try to apply the patch from [1] (?). The code has changed and clearly the patch won't apply cleanly, I gave an eye to the code and, well, as I don't know if it is the same issue, it doesn't seem to me that a good way to start was making the patch match the 0.9.3 release.

3. Is it another issue, but still known? I did a quick search over the issues from gnuradio at git and didn't see something directly related. It doesn't affect the result of the OOT being correctly generated, so maybe I'm spending more time on this while someone is maybe addressing it already.

4. It is a new bug and we should keep digging? well, yeah.

Please feel free to comment on anything that would, at least, provide some understanding on what is going on.

Thanks in advance!

Cheers,

- Nicolas

[1] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gnuradio-runtime/lib/controlport/thrift/README