# Ctest -V segfault, coredump reveals nothing **URL:** \ **Category:** GNU Radio\ **Created:** [April 16, 2014, 10:28pm UTC](https://www.ruby-forum.com/t/ctest-v-segfault-coredump-reveals-nothing/240496 "2014-04-16T22:28:42Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [April 16, 2014, 10:28pm UTC](https://www.ruby-forum.com/t/ctest-v-segfault-coredump-reveals-nothing/240496/1 "2014-04-16T22:28:42Z")
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](http://gnuradio.4.n7.nabble.com/ctest-V-segfault-coredump-reveals-nothing-tp47635.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![kkarranc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/898d66/32.png) [@kkarranc](https://www.ruby-forum.com/u/kkarranc)\ **Post date:** [April 17, 2014, 1:23am UTC](https://www.ruby-forum.com/t/ctest-v-segfault-coredump-reveals-nothing/240496/2 "2014-04-17T01:23:17Z")
> > 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 ---
**Author:** ![kkarranc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/898d66/32.png) [@kkarranc](https://www.ruby-forum.com/u/kkarranc)\ **Post date:** [April 17, 2014, 12:00am UTC](https://www.ruby-forum.com/t/ctest-v-segfault-coredump-reveals-nothing/240496/3 "2014-04-17T00:00:43Z")
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 ---
**Author:** ![kkarranc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/898d66/32.png) [@kkarranc](https://www.ruby-forum.com/u/kkarranc)\ **Post date:** [April 17, 2014, 2:50pm UTC](https://www.ruby-forum.com/t/ctest-v-segfault-coredump-reveals-nothing/240496/4 "2014-04-17T14:50:22Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![kkarranc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/898d66/32.png) [@kkarranc](https://www.ruby-forum.com/u/kkarranc)\ **Post date:** [April 17, 2014, 3:51am UTC](https://www.ruby-forum.com/t/ctest-v-segfault-coredump-reveals-nothing/240496/5 "2014-04-17T03:51:25Z")
On Wed, Apr 16, 2014 at 6:21 PM, Kiran K. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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