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 |
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 _______________________________________________ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio |
>> 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 _______________________________________________ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s (3K) Download Attachment |
On Wed, Apr 16, 2014 at 6:21 PM, Kiran Karra <[hidden email]> wrote:
>>> 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 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 _______________________________________________ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio |
>>> 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, great call. Running the script without the ctest infrastructure yielded a valid stacktrace. I found that it was related to the way I was creating my fft engines. Instead of instantiating an FFT directly, I was creating it w/ a managed_resource_pool_nofactory. I haven't investigated fully why this is causing my program to segfault, but as a quick test I replaced the way I was creating the fft with just this line: fft::fft_complex fft = fft::fft_complex(fftSize); and am not getting the segfaults anymore. I'll have to do some debugging to figure out why this is going on, but atleast I know where to start now. For those that are curious, the backtrace looks like this: Program terminated with signal 11, Segmentation fault. #0 0x0000000000000031 in ?? () (gdb) backtrace #0 0x0000000000000031 in ?? () #1 0x00007f0317592c70 in boost::checked_delete<gr::fft::fft_complex> (x=0xb07430) at /usr/include/boost/checked_delete.hpp:34 #2 0x00007f03175974c0 in boost::detail::sp_counted_impl_p<gr::fft::fft_complex>::dispose (this=0xb065d0) at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #3 0x00007f0317585e02 in boost::detail::sp_counted_base::release (this=0xb065d0) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146 #4 0x00007f0317585e91 in boost::detail::shared_count::~shared_count (this=0xadb240, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #5 0x00007f031759023c in boost::shared_ptr<gr::fft::fft_complex>::~shared_ptr (this=0xadb238, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:328 #6 0x00007f0317593da8 in std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> >::~pair (this=0xadb230, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_pair.h:96 #7 0x00007f0317596378 in __gnu_cxx::new_allocator<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > >::destroy (this=0x7fff820439ef, __p=0xadb230) at /usr/include/c++/4.8/ext/new_allocator.h:133 #8 0x00007f0317595742 in std::_Rb_tree<gr::fft::fft_complex*, std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> >, std::_Select1st<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > >, std::less<gr::fft::fft_complex*>, std::allocator<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > > >::_M_destroy_node (this=0xaca178, __p=0xadb210) at /usr/include/c++/4.8/bits/stl_tree.h:395 #9 0x00007f031759478f in std::_Rb_tree<gr::fft::fft_complex*, std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> >, std::_Select1st<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > >, std::less<gr::fft::fft_complex*>, std::allocator<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > > >::_M_erase (this=0xaca178, __x=0xadb210) at /usr/include/c++/4.8/bits/stl_tree.h:1127 #10 0x00007f0317593c57 in std::_Rb_tree<gr::fft::fft_complex*, std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> >, std::_Select1st<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > >, std::less<gr::fft::fft_complex*>, std::allocator<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > > >::~_Rb_tree (this=0xaca178, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_tree.h:671 #11 0x00007f0317593176 in std::map<gr::fft::fft_complex*, boost::shared_ptr<gr::fft::fft_complex>, std::less<gr::fft::fft_complex*>, std::allocator<std::pair<gr::fft::fft_complex* const, boost::shared_ptr<gr::fft::fft_complex> > > >::~map (this=0xaca178, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_map.h:96 #12 0x00007f03175957e9 in pooled_resource<gr::fft::fft_complex>::~pooled_resource (this=0xaca130, __in_chrg=<optimized out>) at /home/kiran/awst/gnuradio/include/es/pooled_resource.h:20 #13 0x00007f0317595836 in boost::checked_delete<pooled_resource<gr::fft::fft_complex> > (x=0xaca130) at /usr/include/boost/checked_delete.hpp:34 #14 0x00007f031759747e in boost::detail::sp_counted_impl_p<pooled_resource<gr::fft::fft_complex> >::dispose (this=0xaca2e0) at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #15 0x00007f0317585e02 in boost::detail::sp_counted_base::release (this=0xaca2e0) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146 #16 0x00007f0317585e91 in boost::detail::shared_count::~shared_count (this=0xadb1a0, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #17 0x00007f0317591d0a in boost::shared_ptr<pooled_resource<gr::fft::fft_complex> >::~shared_ptr (this=0xadb198, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:328 #18 0x00007f0317591d28 in std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >::~pair (this=0xadb190, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_pair.h:96 #19 0x00007f0317591d46 in __gnu_cxx::new_allocator<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >::destroy (this=0x7fff82043bcf, __p=0xadb190) at /usr/include/c++/4.8/ext/new_allocator.h:133 #20 0x00007f03175912dc in std::_Rb_tree<int, std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, std::_Select1st<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, std::less<int>, std::allocator<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >::_M_destroy_node (this=0xac91c8, __p=0xadb170) at /usr/include/c++/4.8/bits/stl_tree.h:395 #21 0x00007f03175905a7 in std::_Rb_tree<int, std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, std::_Select1st<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, std::less<int>, std::allocator<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >::_M_erase (this=0xac91c8, __x=0xadb170) at /usr/include/c++/4.8/bits/stl_tree.h:1127 #22 0x00007f0317590584 in std::_Rb_tree<int, std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, std::_Select1st<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, std::less<int>, std::allocator<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >::_M_erase (this=0xac91c8, __x=0xac9b80) at /usr/include/c++/4.8/bits/stl_tree.h:1125 #23 0x00007f031758fa95 in std::_Rb_tree<int, std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, std::_Select1st<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, std::less<int>, std::allocator<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >::~_Rb_tree (this=0xac91c8, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_tree.h:671 #24 0x00007f031758f248 in std::map<int, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> >, std::less<int>, std::allocator<std::pair<int const, boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >::~map (this=0xac91c8, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_map.h:96 #25 0x00007f031758f277 in managed_resource_pool<gr::fft::fft_complex, int>::~managed_resource_pool (this=0xac91a8, __in_chrg=<optimized out>) at /home/kiran/awst/gnuradio/include/es/pooled_resource.h:58 #26 0x00007f031758f2be in managed_resource_pool_nofactory<gr::fft::fft_complex, int>::~managed_resource_pool_nofactory (this=0xac91a8, __in_chrg=<optimized out>) at /home/kiran/awst/gnuradio/include/es/pooled_resource.h:115 #27 0x00007f0317598109 in gr::wifi_detector::es_80211b_chip_and_freq_sync_c_impl::~es_80211b_chip_and_freq_sync_c_impl (this=0xac91a0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) ---Type <return> to continue, or q <return> to quit--- at /home/kiran/awst/pybombs/src/gr-ieee-80211b/lib/es_80211b_chip_and_freq_sync_c_impl.cc:73 #28 0x00007f03175981c2 in gr::wifi_detector::es_80211b_chip_and_freq_sync_c_impl::~es_80211b_chip_and_freq_sync_c_impl (this=0xac91a0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/kiran/awst/pybombs/src/gr-ieee-80211b/lib/es_80211b_chip_and_freq_sync_c_impl.cc:75 #29 0x0000000000418a04 in boost::detail::sp_counted_base::release (this=0xb04e10) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146 #30 0x0000000000418a93 in boost::detail::shared_count::~shared_count (this=0x7fff820441c8, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #31 0x0000000000426a74 in boost::shared_ptr<gr::wifi_detector::es_80211b_chip_and_freq_sync_c>::~shared_ptr (this=0x7fff820441c0, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:328 #32 0x0000000000425b38 in gr::wifi_detector::qa_es_80211b_chip_and_freq_sync::t1 (this=0xac8be0) at /home/kiran/awst/pybombs/src/gr-ieee-80211b/lib/qa_es_80211b_chip_and_freq_sync.cc:57 #33 0x000000000041681c in CppUnit::TestCaller<gr::wifi_detector::qa_es_80211b_chip_and_freq_sync>::runTest (this=0xac8e50) at /usr/include/cppunit/TestCaller.h:166 _______________________________________________ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s (3K) Download Attachment |
Free forum by Nabble | Edit this page |