Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

On Tue, Dec 6, 2016 at 1:24 PM, devin kelly <address@hidden> wrote:

I changed my volk_config like so

volk_32fc_32f_dot_prod_32fc generic generic

And I still get a segfault:

gdb python core.8035

 .....

Program terminated with signal 11, Segmentation fault.
#0  0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860,
    num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
83          *realpt += ((*aPtr++) * (*bPtr));
Missing separate debuginfos, use: debuginfo-install python-2.7.5-48.el7.x86_64
(gdb) bt
#0  0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
#1  0x00007f114ffff74f in gr::filter::kernel::fir_filter_ccf::filter(std::complex<float> const*) ()
    at /local_disk/spectrum_challenge/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
#2  0x00007f1150356b41 in gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector<int, std::allocator<int> >&, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) ()
    at /local_disk/spectrum_challenge/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
#3  0x00007f1163d14d80 in gr::block_executor::run_one_iteration() ()
    at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#4  0x00007f1163d56090 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::block>, int) ()
    at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#5  0x00007f1163d49791 in boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>, void>::invoke(boost::detail::function::function_buffer&) ()
    at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#6  0x00007f1163cfae60 in boost::detail::thread_data<boost::function0<void> >::run() ()
    at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#7  0x00007f11627f927a in thread_proxy () at /lib64/libboost_thread-mt.so.1.53.0
#8  0x00007f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
#9  0x00007f117dafe73d in clone () at /lib64/libc.so.6
(gdb) f 0
#0  0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
83          *realpt += ((*aPtr++) * (*bPtr));
(gdb) info locals
res = {0, 0}
realpt = 0x7f114680f570
imagpt = 0x7f114680f574
aPtr = 0x7f1126cac684
bPtr = 0x56ea860
number = 0
(gdb) print realpt
$1 = (float *) 0x7f114680f570
(gdb) print *realpt
$2 = 0
(gdb) print aPtr
$3 = (const float *) 0x7f1126cac684
(gdb) print *aPtr
Cannot access memory at address 0x7f1126cac684
(gdb) print bPtr
$4 = (const float *) 0x56ea860
(gdb) print *bPtr
$5 = 0.000685208186

If I'm doing the arithmetic correctly aPtr is pointing to memory that the caller claimed was valid and we aren't doing anything so funny here that I would expect a segfault. It does appear that this might be a bug you are triggering, but the question is why.

What are your parameters for the clock sync?

Are you able to get a small snapshot of data that will consistently cause this? For example, file source -> pfb clock sync -> null sink which will consistently fail.

Does this occur only with the one modem/data pattern+channel you're working on?