Ctest -V segfault, coredump reveals nothing

GNU Radio
1

Hi All,
I have a gnuradio block which I am testing through a C++ QA function. I
call the handler function directly in C++ QA test function, and
everything
runs.

My test function is structured as follows:

  • I create a pointer to the object I want to create by using the make
    function, which returns a boost::shared_ptr to the object.
  • I then do obj–>handler() to run all the tests and they pass fine
    (The
    reason this is a handler and not a standard work() function is because
    this
    block is based on gr-eventstream and it is a subclass of the es_trigger
    block).
  • At the end, I can see that the destructor to my object is being
    called
    and that completes nicely. However, after desctruction of my object, I
    get
    a segfault from ctest (I am running the test through ctest -V to see
    what is
    going on instead of make test).

I suspect what is going on is something w/ the boost::shared_ptr but I
don’t
know what exactly.

I created a core dump through the usual methods and I can’t get it to
output
anything useful to help me debug the problem. Here is the output of “i
stack”

Core was generated by `test-wifi_detector’.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000000031 in ?? ()
(gdb) i stack
#0 0x0000000000000031 in ?? ()
#1 0x00007f6a7b3ae11e in ?? ()
#2 0x00007fff8cea6d10 in ?? ()
#3 0x0000000002261ab0 in ?? ()
#4 0x00007fff8cea6cf0 in ?? ()
#5 0x00007f6a7b3b178e in ?? ()
#6 0x00007fff8cea7540 in ?? ()
#7 0x00000000022612b0 in ?? ()
#8 0x00007fff8cea6d10 in ?? ()
#9 0x00007f6a7b3a1072 in ?? ()
#10 0x0000000100000000 in ?? ()
#11 0x00000000022612b0 in ?? ()
#12 0x00007fff8cea6d30 in ?? ()
#13 0x00007f6a7b3a1101 in ?? ()
#14 0x00007fff8cea6d40 in ?? ()
#15 0x000000000226ffa0 in ?? ()
#16 0x00007fff8cea6d50 in ?? ()
#17 0x00007f6a7b3aa090 in ?? ()
#18 0x00007fff8cea7120 in ?? ()
#19 0x000000000226ff98 in ?? ()
#20 0x00007fff8cea6d70 in ?? ()
#21 0x00007f6a7b3ace28 in ?? ()
#22 0x000000000224ba88 in ?? ()
#23 0x000000000226ff90 in ?? ()
#24 0x00007fff8cea6d90 in ?? ()
#25 0x00007f6a7b3afc9a in ?? ()
#26 0x000000000226ff90 in ?? ()
#27 0x00007fff8cea6dbf in ?? ()
#28 0x00007fff8cea6dd0 in ?? ()
#29 0x00007f6a7b3aea96 in ?? ()
#30 0x000000000226ff70 in ?? ()
#31 0x000000000224ba88 in ?? ()
#32 0x0000000000000000 in ?? ()

I tried rebuilding with the debug flags enabled during compile by doing
this: cmake -DCMAKE_BUILD_TYPE=Debug …/ && make clean && make && make
install && ctest -V but I still get question marks. As for the
executable
I am passing into gdb, I tried: "test-wifi_detector /bin/bash and
ctest)

Does anybody have any ideas as to how I can proceed to figure out what
is
going on? I am pretty convinced that the block itself is not
segfaulting
because the destructor gets called and that gets cleaned up. Another
reason
why I think the block is OK is because when I run it in a grc flowgraph,
it
works fine … its just in test mode that this happens. Another reason
why
I think this is something with boost::shared_ptr is, in my unittest
function
in C++, if i call sptr.reset(), it segfaults right there (I’ve verified
the
only way I know how, which is with print statements before and after).

Thanks,
Kiran

–
View this message in context:
http://gnuradio.4.n7.nabble.com/ctest-V-segfault-coredump-reveals-nothing-tp47635.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

Any chance you can share the code?

I will try to get some approval here to release, however it may be a bit
of time before I am allowed to do that unfortunately.

Try and remove the .xml-file output from the test and run again. Maybe
it’s a problem of persistence?

I tried this just now, still seg faulting but thanks for the suggestion.

Any ideas as to why I can’t see a stacktrace in GDB even though I
rebuilt the code with debug symbols? That seems strange to me. Tim
suggested that perhaps this is due to ctest swallowing the segfault as a
fail in the test … and I think that is actually what is happening,
because I see ctest move onto the next test. I looked at ctest help but
didn’t find a way for it to not swallow the segfaults… does anybody
have any ideas here?

Thanks again,
Kiran

3

On 04/16/2014 10:27 PM, kkarranc wrote:

Hi All,
I have a gnuradio block which I am testing through a C++ QA function. I
call the handler function directly in C++ QA test function, and everything
runs.

Any chance you can share the code?

Does anybody have any ideas as to how I can proceed to figure out what is
going on? I am pretty convinced that the block itself is not segfaulting
because the destructor gets called and that gets cleaned up. Another reason
why I think the block is OK is because when I run it in a grc flowgraph, it
works fine … its just in test mode that this happens. Another reason why
I think this is something with boost::shared_ptr is, in my unittest function
in C++, if i call sptr.reset(), it segfaults right there (I’ve verified the
only way I know how, which is with print statements before and after).

Try and remove the .xml-file output from the test and run again. Maybe
it’s a problem of persistence?

M

4

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

5

On Wed, Apr 16, 2014 at 6:21 PM, Kiran K. [email protected] wrote:

Kiran
Sounds plausible. Ctest is actually just running a shell script. You
can try running that script through gdb. The name of the script will
be printed near the top of ctest -V. Alternatively you should be able
to find it in
$build/modname/python/namespace/qa_whatever_your_test_is_called.sh;
an example for gr-digital:
build/gr-digital/python/digital/qa_mpsk_snr_est_test.sh

Nathan