Quantcast

ctest -V segfault, coredump reveals nothing

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ctest -V segfault, coredump reveals nothing

kkarranc
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ctest -V segfault, coredump reveals nothing

Martin Braun-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ctest -V segfault, coredump reveals nothing

kkarranc
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ctest -V segfault, coredump reveals nothing

West, Nathan
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ctest -V segfault, coredump reveals nothing

kkarranc
>>> 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
Loading...