Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Andy Walls]

On Wed, 2016-12-07 at 12:10 -0500, Andy Walls wrote:

> > From GDB I can see
> > 
> > 
> > d_filtnum = 0
> > count = -67108696
> > d_out_idx = 0
> > 
> 
> This is a garbage-in, garbage-out problem I've seen exactly before with
> other blocks and the PFB clock sync block.
> 
> 1. Check to make sure that your filter taps don't trace out a function
> that has discontinuities or flat spots (i.e. a square pulse), and the
> PFB clock sync algorithms can't handle that.

typo:  ... *as* the PFB clock sync algorithms can't handle that.

> 2. Add a tag_debug block before the PFB clock_sync and look for time_est
> tags with values outside the range [0.0, 1.0).
> 
> -Andy



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Typo in there count can never be less than 0.

The other thing that I think makes sense is that we might need some history
to scroll back to, but I don't think it's necessarily bounded how much
history... Are you using an upstream block that provides time_est tags?
Also, what parameters are you providing to the clock sync? number of
filters/filter size is the most interesting parameter here, but others
might be useful too.

Nathan

On Wed, Dec 7, 2016 at 12:00 PM, West, Nathan 
wrote:

> Some sanity appears!
>
> From what I can tell, count is keeping track of how many input samples
> have been processed, which can never be 0. My proposed fix would be to
> clamp count to 0 somewhere after line 462, but it would be nice for someone
> to confirm this makes sense.
>
> Nathan
>
> On Wed, Dec 7, 2016 at 10:18 AM, devin kelly  wrote:
>
>> I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
>> optimized out, what's the compiler option to prevent that?
>>
>> I think I've found part of the problem:
>>
>> Looking here (on frame 2 in gdb):
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/
>> lib/pfb_clock_sync_ccf_impl.cc#L465
>>
>> This is the line where filter is called (which is where the segfault
>> occurs):
>>
>> d_filters[d_filtnum]->filter([count+d_out_idx])
>>
>> From GDB I can see
>>
>> d_filtnum = 0
>> count = -67108696
>> d_out_idx = 0
>>
>> (gdb) bt
>> #0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
>> (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
>> /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_
>> 32fc_32f_dot_prod_32fc.h:83
>> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter
>> _ccf::filter(std::complex const*) (this=0x53af290,
>> input=input@entry=0x7fed94b925a0) at /local_disk/spectrum_challenge
>> _src/gnuradio/gr-filter/lib/fir_filter.cc:232
>> #2  0x7fedbe22e041 in 
>> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
>> std::vector&, std::vector> std::allocator >&, std::vector
>> >&) (this=
>> 0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
>> output_items=std::vector of length 1, capacity 1 = {...})
>> at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/
>> pfb_clock_sync_ccf_impl.cc:465
>> #3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
>> (this=this@entry=0x7fedafffedb0)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/block_executor.cc:451
>> #4  0x7fedd1bfc6aa in gr::tpb_thread_body::tpb_threa
>> d_body(boost::shared_ptr, int) (this=0x7fedafffedb0,
>> block=..., max_noutput_items=)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/tpb_thread_body.cc:122
>> #5  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0> void>::invoke(boost::detail::function::function_buffer&)
>> (this=0x53ddc90, this=)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/scheduler_tpb.cc:44
>> #6  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0> void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/include/gnuradio/thread/thread_body_wrapper.h:51
>> #7  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0> void>::invoke(boost::detail::function::function_buffer&)
>> (function_obj_ptr=...)
>> at /usr/include/boost/function/function_template.hpp:153
>> #8  0x7fedd1ba5050 in boost::detail::thread_data> >::run() (this=)
>> at /usr/include/boost/function/function_template.hpp:767
>> #9  0x7fedd1ba5050 in boost::detail::thread_data> >::run() (this=)
>> at /usr/include/boost/thread/detail/thread.hpp:117
>> #10 0x7fedd06a527a in thread_proxy () at
>> /lib64/libboost_thread-mt.so.1.53.0
>> #11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
>> #12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
>> (gdb) f 1
>> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
>> (this=0x53af290, input=input@entry=0x7fed94b925a0)
>> at /local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/
>> fir_filter.cc:232
>> 232   (d_ntaps+al));
>> (gdb) info locals
>> ar = 
>> al = 
>> (gdb) print d_ntaps
>> $1 = 45
>> (gdb) print al
>> $2 = 
>> (gdb) print d_aligned_taps[al]
>> value has been optimized out
>> (gdb) print d_aligned_taps[0]
>>
>>
>>
>> $3 = (float *) 0x53bb9a0
>> (gdb) print d_aligned_taps[1]
>>
>>
>>
>> $4 = (float *) 0x53bbac0
>> (gdb) print input
>> $5 = (const gr_complex *) 0x7fed94b925a0
>> (gdb) print *input
>> Cannot access memory at address 0x7fed94b925a0
>> 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Andy Walls]

>  From: 
> devin kelly
>   Subject: 
> Re: [Discuss-gnuradio] Segfault
> with
> volk_32fc_32f_dot_prod_32fc_a_avx
>  Date: 
> Wed, 7 Dec 2016 10:18:32 -0500
> 
> __


> I think I've found part of the problem:
> 
> 
> Looking here (on frame 2 in gdb):
> 
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L465
> 
> 
> 
> This is the line where filter is called (which is where the segfault
> occurs):
> 
> 
> d_filters[d_filtnum]->filter([count+d_out_idx])
> 
> 
> From GDB I can see
> 
> 
> d_filtnum = 0
> count = -67108696
> d_out_idx = 0
> 

This is a garbage-in, garbage-out problem I've seen exactly before with
other blocks and the PFB clock sync block.

1. Check to make sure that your filter taps don't trace out a function
that has discontinuities or flat spots (i.e. a square pulse), and the
PFB clock sync algorithms can't handle that.

2. Add a tag_debug block before the PFB clock_sync and look for time_est
tags with values outside the range [0.0, 1.0).

-Andy


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Some sanity appears!

>From what I can tell, count is keeping track of how many input samples have
been processed, which can never be 0. My proposed fix would be to clamp
count to 0 somewhere after line 462, but it would be nice for someone to
confirm this makes sense.

Nathan

On Wed, Dec 7, 2016 at 10:18 AM, devin kelly  wrote:

> I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
> optimized out, what's the compiler option to prevent that?
>
> I think I've found part of the problem:
>
> Looking here (on frame 2 in gdb):
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc#L465
>
> This is the line where filter is called (which is where the segfault
> occurs):
>
> d_filters[d_filtnum]->filter([count+d_out_idx])
>
> From GDB I can see
>
> d_filtnum = 0
> count = -67108696
> d_out_idx = 0
>
> (gdb) bt
> #0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> #1  0x7fedbdedcc3f in 
> gr::filter::kernel::fir_filter_ccf::filter(std::complex
> const*) (this=0x53af290, input=input@entry=0x7fed94b925a0) at
> /local_disk/spectrum_challenge_src/gnuradio/gr-
> filter/lib/fir_filter.cc:232
> #2  0x7fedbe22e041 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector
> >&) (this=
> 0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
> output_items=std::vector of length 1, capacity 1 = {...})
> at /local_disk/spectrum_challenge_src/gnuradio/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc:465
> #3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
> (this=this@entry=0x7fedafffedb0)
> at /local_disk/spectrum_challenge_src/gnuradio/
> gnuradio-runtime/lib/block_executor.cc:451
> #4  0x7fedd1bfc6aa in gr::tpb_thread_body::tpb_
> thread_body(boost::shared_ptr, int) (this=0x7fedafffedb0,
> block=..., max_noutput_items=)
> at /local_disk/spectrum_challenge_src/gnuradio/
> gnuradio-runtime/lib/tpb_thread_body.cc:122
> #5  0x7fedd1bf0ed1 in boost::detail::function::void_
> function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90,
> this=)
> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/
> scheduler_tpb.cc:44
> #6  0x7fedd1bf0ed1 in boost::detail::function::void_
> function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
> at /local_disk/spectrum_challenge_src/gnuradio/
> gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
> #7  0x7fedd1bf0ed1 in boost::detail::function::void_
> function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...)
> at /usr/include/boost/function/function_template.hpp:153
> #8  0x7fedd1ba5050 in boost::detail::thread_data >::run() (this=)
> at /usr/include/boost/function/function_template.hpp:767
> #9  0x7fedd1ba5050 in boost::detail::thread_data >::run() (this=)
> at /usr/include/boost/thread/detail/thread.hpp:117
> #10 0x7fedd06a527a in thread_proxy () at /lib64/libboost_thread-mt.so.
> 1.53.0
> #11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
> #12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
> (gdb) f 1
> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
> (this=0x53af290, input=input@entry=0x7fed94b925a0)
> at /local_disk/spectrum_challenge_src/gnuradio/gr-
> filter/lib/fir_filter.cc:232
> 232   (d_ntaps+al));
> (gdb) info locals
> ar = 
> al = 
> (gdb) print d_ntaps
> $1 = 45
> (gdb) print al
> $2 = 
> (gdb) print d_aligned_taps[al]
> value has been optimized out
> (gdb) print d_aligned_taps[0]
>
>
>
> $3 = (float *) 0x53bb9a0
> (gdb) print d_aligned_taps[1]
>
>
>
> $4 = (float *) 0x53bbac0
> (gdb) print input
> $5 = (const gr_complex *) 0x7fed94b925a0
> (gdb) print *input
> Cannot access memory at address 0x7fed94b925a0
> (gdb) print real(*input)
> No symbol "real" in current context.
> (gdb) print ar
> $6 = 
>
> (gdb) f 2
> #2  0x7fedbe22e041 in gr::digital::pfb_clock_sync_ccf_impl::general_work
> (this=0x53a1800, noutput_items=256,
> ninput_items=..., input_items=..., output_items=std::vector of length
> 1, capacity 1 = {...})
> at /local_disk/spectrum_challenge_src/gnuradio/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc:465
> 465   out[i+d_out_idx] = d_filters[d_filtnum]->filter(&
> in[count+d_out_idx]);
> (gdb) print d_filtnum
> $7 = 0
> (gdb) print count
> $8 = -67108696
> (gdb) print d_out_idx
> $9 = 0
> (gdb) print in
> $10 = 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
optimized out, what's the compiler option to prevent that?

I think I've found part of the problem:

Looking here (on frame 2 in gdb):

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L465

This is the line where filter is called (which is where the segfault
occurs):

d_filters[d_filtnum]->filter([count+d_out_idx])

>From GDB I can see

d_filtnum = 0
count = -67108696
d_out_idx = 0

(gdb) bt
#0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
(result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
/local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
#1  0x7fedbdedcc3f in
gr::filter::kernel::fir_filter_ccf::filter(std::complex const*)
(this=0x53af290, input=input@entry=0x7fed94b925a0) at
/local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/fir_filter.cc:232
#2  0x7fedbe22e041 in
gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector&, std::vector >&, std::vector >&) (this=
0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
output_items=std::vector of length 1, capacity 1 = {...})
at
/local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/pfb_clock_sync_ccf_impl.cc:465
#3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
(this=this@entry=0x7fedafffedb0)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:451
#4  0x7fedd1bfc6aa in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
(this=0x7fedafffedb0, block=..., max_noutput_items=)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
#5  0x7fedd1bf0ed1 in
boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90,
this=)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
#6  0x7fedd1bf0ed1 in
boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
#7  0x7fedd1bf0ed1 in
boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::function_buffer&)
(function_obj_ptr=...)
at /usr/include/boost/function/function_template.hpp:153
#8  0x7fedd1ba5050 in boost::detail::thread_data::run() (this=)
at /usr/include/boost/function/function_template.hpp:767
#9  0x7fedd1ba5050 in boost::detail::thread_data::run() (this=)
at /usr/include/boost/thread/detail/thread.hpp:117
#10 0x7fedd06a527a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
#12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
(gdb) f 1
#1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
(this=0x53af290, input=input@entry=0x7fed94b925a0)
at
/local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/fir_filter.cc:232
232   (d_ntaps+al));
(gdb) info locals
ar = 
al = 
(gdb) print d_ntaps
$1 = 45
(gdb) print al
$2 = 
(gdb) print d_aligned_taps[al]
value has been optimized out
(gdb) print
d_aligned_taps[0]

$3 = (float *) 0x53bb9a0
(gdb) print
d_aligned_taps[1]

$4 = (float *) 0x53bbac0
(gdb) print input
$5 = (const gr_complex *) 0x7fed94b925a0
(gdb) print *input
Cannot access memory at address 0x7fed94b925a0
(gdb) print real(*input)
No symbol "real" in current context.
(gdb) print ar
$6 = 

(gdb) f 2
#2  0x7fedbe22e041 in
gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x53a1800,
noutput_items=256,
ninput_items=..., input_items=..., output_items=std::vector of length
1, capacity 1 = {...})
at
/local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/pfb_clock_sync_ccf_impl.cc:465
465   out[i+d_out_idx] =
d_filters[d_filtnum]->filter([count+d_out_idx]);
(gdb) print d_filtnum
$7 = 0
(gdb) print count
$8 = -67108696
(gdb) print d_out_idx
$9 = 0
(gdb) print in
$10 = (gr_complex *) 0x7fedb4b92060
(gdb) print count+d_out_idx
$11 = -67108696
(gdb) in[count+d_out_idx]
Ambiguous command "in[count+d_out_idx]": .
(gdb) print in[count+d_out_idx]
Cannot access memory at address 0x7fed94b925a0






On Tue, Dec 6, 2016 at 2:04 PM, Marcus Müller 
wrote:

> Hi,
> hm, you're right, the only way that can happen is if either the input or
> the tap pointers are invalid; strange.
>
> Since the line in question,
>  465   out[i+d_out_idx] = d_filters[d_filtnum]->filter(&
> in[count+d_out_idx]);
> in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GDB 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Marcus Müller]

Hi,

hm, you're right, the only way that can happen is if either the input or
the tap pointers are invalid; strange.

Since the line in question,
 465   out[i+d_out_idx] =
d_filters[d_filtnum]->filter([count+d_out_idx]);
in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GDB for
a moment.

1. since you're in stack frame #0 by default, can you see whether you
can `print number` from the gdb shell? It's possible that GCC optimized
that variable away, so try `print bPtr`, too.
2. From 1. we know whether this happens on the first loop iteration or a
subsequent one; that will show in which direction we'd look for bugs
3. `frame 1` brings us into the context of the fir_filter_ccf::filter
function. `print al` and `print d_ntaps`, please!
4. We're getting a bit fancy here with gdb, but whatever :) `print
d_aligned_taps[al]`

Hope this gives us a push forward!

Greetings,
Marcus


On 12/06/2016 07:24 PM, devin kelly 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  0x7f116379277f 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  0x7f116379277f 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  0x7f11474f in
> gr::filter::kernel::fir_filter_ccf::filter(std::complex const*) ()
> at
> /local_disk/spectrum_challenge/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
> #2  0x7f1150356b41 in
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector std::allocator >&) ()
> at
> /local_disk/spectrum_challenge/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
> #3  0x7f1163d14d80 in gr::block_executor::run_one_iteration() ()
> at
> /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #4  0x7f1163d56090 in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
> at
> /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #5  0x7f1163d49791 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) ()
> at
> /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #6  0x7f1163cfae60 in
> boost::detail::thread_data::run() ()
> at
> /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #7  0x7f11627f927a in thread_proxy () at
> /lib64/libboost_thread-mt.so.1.53.0
> #8  0x7f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
> #9  0x7f117dafe73d in clone () at /lib64/libc.so.6
> (gdb) f 0
> #0  0x7f116379277f 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
>
>
> The fault happens here:
>
> https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L83
>
>
> Since aPtr is just
>
> const float* aPtr = (float*)input;
>
> Maybe the issue is with pfb_clock_sync_ccf_impl?  I'm not sure.
>
> Devin
>
> On Tue, Dec 6, 2016 at 1:06 PM, devin kelly  > wrote:
>
> It's a bit of both.  The segfault usually happens on packet
> between packets 2 and 3 (I send one packet per second on my
> transmitter) but sometimes will happen a few packets later.  It
> also always segfaults, I've gotten it to segfault about 20 times
> or so.
>
> On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan
> >
> wrote:
>
> Honestly, my money would be on GCC 4.8.5 being less buggy than
> 6.2, but that's a separate topic.
>
> You can configure VOLK to not use this protokernel and there's
> some documentation on how to 

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  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  0x7f116379277f 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  0x7f116379277f 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  0x7f11474f in 
> gr::filter::kernel::fir_filter_ccf::filter(std::complex
> const*) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> filter-3.7.10.1.so.0.0.0
> #2  0x7f1150356b41 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector
> >&) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> digital-3.7.10.1.so.0.0.0
> #3  0x7f1163d14d80 in gr::block_executor::run_one_iteration() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #4  0x7f1163d56090 in gr::tpb_thread_body::tpb_
> thread_body(boost::shared_ptr, int) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #5  0x7f1163d49791 in boost::detail::function::void_
> function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #6  0x7f1163cfae60 in boost::detail::thread_data >::run() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #7  0x7f11627f927a in thread_proxy () at /lib64/libboost_thread-mt.so.
> 1.53.0
> #8  0x7f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
> #9  0x7f117dafe73d in clone () at /lib64/libc.so.6
> (gdb) f 0
> #0  0x7f116379277f 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?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

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  0x7f116379277f 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  0x7f116379277f 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  0x7f11474f in
gr::filter::kernel::fir_filter_ccf::filter(std::complex const*) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
#2  0x7f1150356b41 in
gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector&, std::vector >&, std::vector >&) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
#3  0x7f1163d14d80 in gr::block_executor::run_one_iteration() ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#4  0x7f1163d56090 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#5  0x7f1163d49791 in
boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::function_buffer&) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#6  0x7f1163cfae60 in boost::detail::thread_data::run() ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#7  0x7f11627f927a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#8  0x7f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
#9  0x7f117dafe73d in clone () at /lib64/libc.so.6
(gdb) f 0
#0  0x7f116379277f 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


The fault happens here:

https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L83


Since aPtr is just

const float* aPtr = (float*)input;

Maybe the issue is with pfb_clock_sync_ccf_impl?  I'm not sure.

Devin

On Tue, Dec 6, 2016 at 1:06 PM, devin kelly  wrote:

> It's a bit of both.  The segfault usually happens on packet between
> packets 2 and 3 (I send one packet per second on my transmitter) but
> sometimes will happen a few packets later.  It also always segfaults, I've
> gotten it to segfault about 20 times or so.
>
> On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan  > wrote:
>
>> Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
>> that's a separate topic.
>>
>> You can configure VOLK to not use this protokernel and there's some
>> documentation on how to do it here: http://gnuradio.org/doc/
>> doxygen/volk_guide.html#volk_tuning
>>
>> This is fairly concerning though... are you able to consistently trigger
>> a segfault or is it a seemingly random event that you can't trigger?
>>
>> On Tue, Dec 6, 2016 at 11:48 AM, devin kelly  wrote:
>>
>>> OK, I tried a brand new GR/Volk install and still had the same problem.
>>> So no problem with re-linking Volk to GR.  Could this be an issue with Volk
>>> on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the
>>> newest for Red Hat 7.  Is there any way to reconfigure volk to not use
>>> volk_32fc_32f_dot_prod_32fc_a_avx?
>>>
>>> Here's volk-config-info:
>>>
>>> $ volk-config-info --all --prefix --cc --cflags --avail-machines
>>> --machine --alignment --malloc
>>> /local_disk/spectrum_challenge
>>> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> This is free software see the source for copying conditions.  There is
>>> NO
>>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>> /usr/bin/cc:::  -Wall
>>> /usr/bin/c++:::  -Wall
>>> generic_orc:::GNU:::-g  -Wall
>>> sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
>>> 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

It's a bit of both.  The segfault usually happens on packet between packets
2 and 3 (I send one packet per second on my transmitter) but sometimes will
happen a few packets later.  It also always segfaults, I've gotten it to
segfault about 20 times or so.

On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan 
wrote:

> Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
> that's a separate topic.
>
> You can configure VOLK to not use this protokernel and there's some
> documentation on how to do it here: http://gnuradio.org/doc/
> doxygen/volk_guide.html#volk_tuning
>
> This is fairly concerning though... are you able to consistently trigger a
> segfault or is it a seemingly random event that you can't trigger?
>
> On Tue, Dec 6, 2016 at 11:48 AM, devin kelly  wrote:
>
>> OK, I tried a brand new GR/Volk install and still had the same problem.
>> So no problem with re-linking Volk to GR.  Could this be an issue with Volk
>> on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the
>> newest for Red Hat 7.  Is there any way to reconfigure volk to not use
>> volk_32fc_32f_dot_prod_32fc_a_avx?
>>
>> Here's volk-config-info:
>>
>> $ volk-config-info --all --prefix --cc --cflags --avail-machines
>> --machine --alignment --malloc
>> /local_disk/spectrum_challenge
>> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software see the source for copying conditions.  There is NO
>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> /usr/bin/cc:::  -Wall
>> /usr/bin/c++:::  -Wall
>> generic_orc:::GNU:::-g  -Wall
>> sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
>> sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
>> sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> -msse4a -mpopcnt
>> sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> -mssse3 -msse4.1
>> sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> -mssse3 -msse4.1 -msse4.2 -mpopcnt
>> avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
>> -msse4.1 -msse4.2 -mpopcnt -mavx
>> avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
>> -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc
>> ;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_
>> 64_mmx_orc;avx2_64_mmx_orc;
>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc
>> ;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
>> avx2_64_mmx_orc
>> Alignment in bytes: 32
>> Used malloc implementation: posix_memalign
>>
>>
>> Thanks again for any help,
>> Devin
>>
>>
>> On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller 
>> wrote:
>>
>>> Oh, that's pretty interesting! Well, no misconfiguration should
>>> segfault, so I'm a bit stumped at the moment.
>>>
>>> On 12/01/2016 06:14 PM, devin kelly wrote:
>>>
>>> Marcus,
>>>
>>> Thanks for taking the time.  It is possible I re-installed a new version
>>> of VOLK.  I'll try a fresh build and see what that gets me.
>>>
>>> I also should have mentioned that the filter works OK for a while then
>>> segfaults.  A couple of packets always pass through the clock sync block
>>> I'm using before I get the segfault.  Finally, the segfault occurs in the
>>> polyphase clock sync block, do you think I could have mis-configured the
>>> block in some way that will get me this error?  I think the PF clock sync
>>> block is pretty popular so if there's a bug in that block that's causing
>>> this I'd be surprised.
>>>
>>> Devin
>>>
>>> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller >> > wrote:
>>>
 Hi Devin,

 I don't think it's a kernel problem – all your calculations happen in
 userland, and the kernel has not much to say with respect to the
 instructions used.

 The most common reason for this kind of misbehaviour is in fact a
 problem with how the application (in this case, your GNU Radio
 application's block) calls into the library function (in this case the VOLK
 dot product).

 Is it possible that for some reason, GNU Radio used a previous version
 of VOLK when you linked it, and then the new version of VOLK was installed?

 Best regards,

 Marcus

 On 12/01/2016 05:23 PM, devin kelly wrote:

 Hello,

 I'm having a problem with the above VOLK function segfaulting.  I don't
 think I'm passing any incorrect values to VOLK.  My problem could be that
 I'm on RHEL7 with (obviously) an older kernel:

 $ uname -a
 Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23
 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

 I'm on VOLK 1.3 and GR 3.7.10.1.

 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
that's a separate topic.

You can configure VOLK to not use this protokernel and there's some
documentation on how to do it here:
http://gnuradio.org/doc/doxygen/volk_guide.html#volk_tuning

This is fairly concerning though... are you able to consistently trigger a
segfault or is it a seemingly random event that you can't trigger?

On Tue, Dec 6, 2016 at 11:48 AM, devin kelly  wrote:

> OK, I tried a brand new GR/Volk install and still had the same problem.
> So no problem with re-linking Volk to GR.  Could this be an issue with Volk
> on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the
> newest for Red Hat 7.  Is there any way to reconfigure volk to not use
> volk_32fc_32f_dot_prod_32fc_a_avx?
>
> Here's volk-config-info:
>
> $ volk-config-info --all --prefix --cc --cflags --avail-machines --machine
> --alignment --malloc
> /local_disk/spectrum_challenge
> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software see the source for copying conditions.  There is NO
> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> /usr/bin/cc:::  -Wall
> /usr/bin/c++:::  -Wall
> generic_orc:::GNU:::-g  -Wall
> sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
> sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
> ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a
> -mpopcnt
> sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1
> sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 -mpopcnt
> avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 -mpopcnt -mavx
> avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_
> orc;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;
> avx_64_mmx_orc;avx2_64_mmx_orc;
> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_
> orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
> avx2_64_mmx_orc
> Alignment in bytes: 32
> Used malloc implementation: posix_memalign
>
>
> Thanks again for any help,
> Devin
>
>
> On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller 
> wrote:
>
>> Oh, that's pretty interesting! Well, no misconfiguration should segfault,
>> so I'm a bit stumped at the moment.
>>
>> On 12/01/2016 06:14 PM, devin kelly wrote:
>>
>> Marcus,
>>
>> Thanks for taking the time.  It is possible I re-installed a new version
>> of VOLK.  I'll try a fresh build and see what that gets me.
>>
>> I also should have mentioned that the filter works OK for a while then
>> segfaults.  A couple of packets always pass through the clock sync block
>> I'm using before I get the segfault.  Finally, the segfault occurs in the
>> polyphase clock sync block, do you think I could have mis-configured the
>> block in some way that will get me this error?  I think the PF clock sync
>> block is pretty popular so if there's a bug in that block that's causing
>> this I'd be surprised.
>>
>> Devin
>>
>> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller 
>> wrote:
>>
>>> Hi Devin,
>>>
>>> I don't think it's a kernel problem – all your calculations happen in
>>> userland, and the kernel has not much to say with respect to the
>>> instructions used.
>>>
>>> The most common reason for this kind of misbehaviour is in fact a
>>> problem with how the application (in this case, your GNU Radio
>>> application's block) calls into the library function (in this case the VOLK
>>> dot product).
>>>
>>> Is it possible that for some reason, GNU Radio used a previous version
>>> of VOLK when you linked it, and then the new version of VOLK was installed?
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 12/01/2016 05:23 PM, devin kelly wrote:
>>>
>>> Hello,
>>>
>>> I'm having a problem with the above VOLK function segfaulting.  I don't
>>> think I'm passing any incorrect values to VOLK.  My problem could be that
>>> I'm on RHEL7 with (obviously) an older kernel:
>>>
>>> $ uname -a
>>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
>>> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> I'm on VOLK 1.3 and GR 3.7.10.1.
>>>
>>> it segfaults here:
>>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol
>>> k_32fc_32f_dot_prod_32fc.h#L119
>>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes
>>> this pointer to VOLK so maybe it's a GR problem?
>>>
>>> I've copied the output of a GDB session and my CPU info below.
>>>
>>> Thanks for any help,
>>> Devin
>>>
>>>
>>>
>>> Program terminated with signal 11, Segmentation fault.
>>> #0  0x7fea7b1bd8b7 in 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

OK, I tried a brand new GR/Volk install and still had the same problem.  So
no problem with re-linking Volk to GR.  Could this be an issue with Volk on
GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the newest
for Red Hat 7.  Is there any way to reconfigure volk to not use
volk_32fc_32f_dot_prod_32fc_a_avx?

Here's volk-config-info:

$ volk-config-info --all --prefix --cc --cflags --avail-machines --machine
--alignment --malloc
/local_disk/spectrum_challenge
cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software see the source for copying conditions.  There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/usr/bin/cc:::  -Wall
/usr/bin/c++:::  -Wall
generic_orc:::GNU:::-g  -Wall
sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a
-mpopcnt
sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1
sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt
avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt -mavx
avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
avx2_64_mmx_orc
Alignment in bytes: 32
Used malloc implementation: posix_memalign


Thanks again for any help,
Devin


On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller 
wrote:

> Oh, that's pretty interesting! Well, no misconfiguration should segfault,
> so I'm a bit stumped at the moment.
>
> On 12/01/2016 06:14 PM, devin kelly wrote:
>
> Marcus,
>
> Thanks for taking the time.  It is possible I re-installed a new version
> of VOLK.  I'll try a fresh build and see what that gets me.
>
> I also should have mentioned that the filter works OK for a while then
> segfaults.  A couple of packets always pass through the clock sync block
> I'm using before I get the segfault.  Finally, the segfault occurs in the
> polyphase clock sync block, do you think I could have mis-configured the
> block in some way that will get me this error?  I think the PF clock sync
> block is pretty popular so if there's a bug in that block that's causing
> this I'd be surprised.
>
> Devin
>
> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller 
> wrote:
>
>> Hi Devin,
>>
>> I don't think it's a kernel problem – all your calculations happen in
>> userland, and the kernel has not much to say with respect to the
>> instructions used.
>>
>> The most common reason for this kind of misbehaviour is in fact a problem
>> with how the application (in this case, your GNU Radio application's block)
>> calls into the library function (in this case the VOLK dot product).
>>
>> Is it possible that for some reason, GNU Radio used a previous version of
>> VOLK when you linked it, and then the new version of VOLK was installed?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 12/01/2016 05:23 PM, devin kelly wrote:
>>
>> Hello,
>>
>> I'm having a problem with the above VOLK function segfaulting.  I don't
>> think I'm passing any incorrect values to VOLK.  My problem could be that
>> I'm on RHEL7 with (obviously) an older kernel:
>>
>> $ uname -a
>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
>> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> I'm on VOLK 1.3 and GR 3.7.10.1.
>>
>> it segfaults here:
>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol
>> k_32fc_32f_dot_prod_32fc.h#L119
>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes this
>> pointer to VOLK so maybe it's a GR problem?
>>
>> I've copied the output of a GDB session and my CPU info below.
>>
>> Thanks for any help,
>> Devin
>>
>>
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>> 835   return *(__m256 *)__P;
>> Missing separate debuginfos, use: debuginfo-install
>> python-2.7.5-48.el7.x86_64
>> (gdb) bt
>> #0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
>> (__P=0x7fea5c3014c0) at /usr/lib/gcc/x86_64-redhat-lin
>> ux/4.8.5/include/avxintrin.h:835
>> #1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
>> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_
>> dot_prod_32fc.h:119
>> #2  0x7fea6661d88f in 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Marcus Müller]

Oh, that's pretty interesting! Well, no misconfiguration should
segfault, so I'm a bit stumped at the moment.


On 12/01/2016 06:14 PM, devin kelly wrote:
> Marcus,
>
> Thanks for taking the time.  It is possible I re-installed a new
> version of VOLK.  I'll try a fresh build and see what that gets me. 
>
> I also should have mentioned that the filter works OK for a while then
> segfaults.  A couple of packets always pass through the clock sync
> block I'm using before I get the segfault.  Finally, the segfault
> occurs in the polyphase clock sync block, do you think I could have
> mis-configured the block in some way that will get me this error?  I
> think the PF clock sync block is pretty popular so if there's a bug in
> that block that's causing this I'd be surprised.
>
> Devin
>
> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller
> > wrote:
>
> Hi Devin,
>
> I don't think it's a kernel problem – all your calculations happen
> in userland, and the kernel has not much to say with respect to
> the instructions used.
>
> The most common reason for this kind of misbehaviour is in fact a
> problem with how the application (in this case, your GNU Radio
> application's block) calls into the library function (in this case
> the VOLK dot product).
>
> Is it possible that for some reason, GNU Radio used a previous
> version of VOLK when you linked it, and then the new version of
> VOLK was installed?
>
> Best regards,
>
> Marcus
>
>
> On 12/01/2016 05:23 PM, devin kelly wrote:
>> Hello,
>>
>> I'm having a problem with the above VOLK function segfaulting.  I
>> don't think I'm passing any incorrect values to VOLK.  My problem
>> could be that I'm on RHEL7 with (obviously) an older kernel:
>>
>> $ uname -a
>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23
>> 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> I'm on VOLK 1.3 and GR 3.7.10.1.
>>
>> it segfaults here:
>> 
>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L119
>> 
>> 
>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR
>> passes this pointer to VOLK so maybe it's a GR problem?
>>
>> I've copied the output of a GDB session and my CPU info below.
>>
>> Thanks for any help,
>> Devin
>>
>>
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>> 835   return *(__m256 *)__P;
>> Missing separate debuginfos, use: debuginfo-install
>> python-2.7.5-48.el7.x86_64
>> (gdb) bt
>> #0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
>> (__P=0x7fea5c3014c0) at
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>> #1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
>> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00,
>> num_points=47) at
>> 
>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
>> #2  0x7fea6661d88f in
>> gr::filter::kernel::fir_filter_ccf::filter(std::complex
>> const*) () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so
>> .0.0.0
>> #3  0x7fea66c01d01 in
>> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
>> std::vector&, std::vector> std::allocator >&, std::vector> std::allocator >&) ()
>> at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
>> #4  0x7fea7b73fe10 in gr::block_executor::run_one_iteration()
>> () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
>> #5  0x7fea7b781120 in
>> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
>> int) () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
>> #6  0x7fea7b774821 in
>> 
>> boost::detail::function::void_function_obj_invoker0> void>::invoke(boost::detail::function::function_buffer&) () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
>> #7  0x7fea7b725ef0 in
>> boost::detail::thread_data::run() () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
>> #8  0x7fea7a22427a in thread_proxy () at
>> /lib64/libboost_thread-mt.so.1.53.0
>> #9  0x7fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
>> #10 0x7fea9571973d in clone () at /lib64/libc.so.6
>> (gdb) print __P
>> $1 = (const float *) 0x7fea5c3014c0
>> (gdb) print *__P
>> Cannot access memory 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

Marcus,

Thanks for taking the time.  It is possible I re-installed a new version of
VOLK.  I'll try a fresh build and see what that gets me.

I also should have mentioned that the filter works OK for a while then
segfaults.  A couple of packets always pass through the clock sync block
I'm using before I get the segfault.  Finally, the segfault occurs in the
polyphase clock sync block, do you think I could have mis-configured the
block in some way that will get me this error?  I think the PF clock sync
block is pretty popular so if there's a bug in that block that's causing
this I'd be surprised.

Devin

On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller 
wrote:

> Hi Devin,
>
> I don't think it's a kernel problem – all your calculations happen in
> userland, and the kernel has not much to say with respect to the
> instructions used.
>
> The most common reason for this kind of misbehaviour is in fact a problem
> with how the application (in this case, your GNU Radio application's block)
> calls into the library function (in this case the VOLK dot product).
>
> Is it possible that for some reason, GNU Radio used a previous version of
> VOLK when you linked it, and then the new version of VOLK was installed?
>
> Best regards,
>
> Marcus
>
> On 12/01/2016 05:23 PM, devin kelly wrote:
>
> Hello,
>
> I'm having a problem with the above VOLK function segfaulting.  I don't
> think I'm passing any incorrect values to VOLK.  My problem could be that
> I'm on RHEL7 with (obviously) an older kernel:
>
> $ uname -a
> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> I'm on VOLK 1.3 and GR 3.7.10.1.
>
> it segfaults here:
> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol
> k_32fc_32f_dot_prod_32fc.h#L119
> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes this
> pointer to VOLK so maybe it's a GR problem?
>
> I've copied the output of a GDB session and my CPU info below.
>
> Thanks for any help,
> Devin
>
>
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> 835   return *(__m256 *)__P;
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-48.el7.x86_64
> (gdb) bt
> #0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
> (__P=0x7fea5c3014c0) at /usr/lib/gcc/x86_64-redhat-lin
> ux/4.8.5/include/avxintrin.h:835
> #1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_
> dot_prod_32fc.h:119
> #2  0x7fea6661d88f in gr::filter::kernel::fir_filter
> _ccf::filter(std::complex const*) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
> #3  0x7fea66c01d01 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector
> >&) ()
> at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
> #4  0x7fea7b73fe10 in gr::block_executor::run_one_iteration() () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #5  0x7fea7b781120 in gr::tpb_thread_body::tpb_threa
> d_body(boost::shared_ptr, int) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #6  0x7fea7b774821 in boost::detail::function::void_
> function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #7  0x7fea7b725ef0 in boost::detail::thread_data >::run() () at /local_disk/gr_3.7.10.1/lib64/
> libgnuradio-runtime-3.7.10.1.so.0.0.0
> #8  0x7fea7a22427a in thread_proxy () at /lib64/libboost_thread-mt.so.1
> .53.0
> #9  0x7fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
> #10 0x7fea9571973d in clone () at /lib64/libc.so.6
> (gdb) print __P
> $1 = (const float *) 0x7fea5c3014c0
> (gdb) print *__P
> Cannot access memory at address 0x7fea5c3014c0
> (gdb) print *(__m256 *)__P
> Cannot access memory at address 0x7fea5c3014c0
> (gdb) f 1
> #1  volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160,
> input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_
> dot_prod_32fc.h:119
> 119 a0Val = _mm256_load_ps(aPtr);
> (gdb) info locals
> number = 0
> sixteenthPoints = 2
> res = {-1.30492652e+29, 0.0779444203}
> realpt = 0x7fea57ffde50
> imagpt = 0x7fea57ffde54
> aPtr = 0x7fea5c3014c0
> bPtr = 0x3671a00
> a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127,
> -0.869615495, -0.869560063, -0.887507021, -0.885902643}
> a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977,
> -0.0328192525, 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Marcus Müller]

Hi Devin,

I don't think it's a kernel problem – all your calculations happen in
userland, and the kernel has not much to say with respect to the
instructions used.

The most common reason for this kind of misbehaviour is in fact a
problem with how the application (in this case, your GNU Radio
application's block) calls into the library function (in this case the
VOLK dot product).

Is it possible that for some reason, GNU Radio used a previous version
of VOLK when you linked it, and then the new version of VOLK was installed?

Best regards,

Marcus


On 12/01/2016 05:23 PM, devin kelly wrote:
> Hello,
>
> I'm having a problem with the above VOLK function segfaulting.  I
> don't think I'm passing any incorrect values to VOLK.  My problem
> could be that I'm on RHEL7 with (obviously) an older kernel:
>
> $ uname -a
> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23
> 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> I'm on VOLK 1.3 and GR 3.7.10.1.
>
> it segfaults here:
> https://github.com/gnuradio/volk/blob/maint/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L119
> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes
> this pointer to VOLK so maybe it's a GR problem?
>
> I've copied the output of a GDB session and my CPU info below.
>
> Thanks for any help,
> Devin
>
>
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> 835   return *(__m256 *)__P;
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-48.el7.x86_64
> (gdb) bt
> #0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
> (__P=0x7fea5c3014c0) at
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> #1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00,
> num_points=47) at
> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
> #2  0x7fea6661d88f in
> gr::filter::kernel::fir_filter_ccf::filter(std::complex const*)
> () at /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
> #3  0x7fea66c01d01 in
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector std::allocator >&) ()
> at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
> #4  0x7fea7b73fe10 in gr::block_executor::run_one_iteration() ()
> at /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #5  0x7fea7b781120 in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
> int) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #6  0x7fea7b774821 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #7  0x7fea7b725ef0 in
> boost::detail::thread_data::run() () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #8  0x7fea7a22427a in thread_proxy () at
> /lib64/libboost_thread-mt.so.1.53.0
> #9  0x7fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
> #10 0x7fea9571973d in clone () at /lib64/libc.so.6
> (gdb) print __P
> $1 = (const float *) 0x7fea5c3014c0
> (gdb) print *__P
> Cannot access memory at address 0x7fea5c3014c0
> (gdb) print *(__m256 *)__P
> Cannot access memory at address 0x7fea5c3014c0
> (gdb) f 1
> #1  volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160,
> input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
> 119 a0Val = _mm256_load_ps(aPtr);
> (gdb) info locals
> number = 0
> sixteenthPoints = 2
> res = {-1.30492652e+29, 0.0779444203}
> realpt = 0x7fea57ffde50
> imagpt = 0x7fea57ffde54
> aPtr = 0x7fea5c3014c0
> bPtr = 0x3671a00
> a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127,
> -0.869615495, -0.869560063, -0.887507021, -0.885902643}
> a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977,
> -0.0328192525, -0.0346645005, 0.376206338, 0.374125361}
> a2Val = {0.711783648, 0.711464763, 0.931477308, 0.933318734,
> 1.01744843, 1.01973152, 0.954917312, 0.955377996}
> a3Val = {0.734342158, 0.732418418, 0.374049634, 0.371605545,
> -0.0585254543, -0.0588675328, -0.461206883, -0.458686352}
> b0Val = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
> 0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293}
> b1Val = {-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193,
> 0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
> b2Val = {0, 0, 0.22138992, 0.22138992, -0.0485430211, -0.0485430211,
> -0.00614725193, -0.00614725193}
> b3Val = {0.0158917159, 0.0158917159, -0.00727195293, -0.00727195293,
> -0.00242348039, 

[Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

Hello,

I'm having a problem with the above VOLK function segfaulting.  I don't
think I'm passing any incorrect values to VOLK.  My problem could be that
I'm on RHEL7 with (obviously) an older kernel:

$ uname -a
Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
EST 2016 x86_64 x86_64 x86_64 GNU/Linux

I'm on VOLK 1.3 and GR 3.7.10.1.

it segfaults here:
https://github.com/gnuradio/volk/blob/maint/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L119
It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes this
pointer to VOLK so maybe it's a GR problem?

I've copied the output of a GDB session and my CPU info below.

Thanks for any help,
Devin



Program terminated with signal 11, Segmentation fault.
#0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
835   return *(__m256 *)__P;
Missing separate debuginfos, use: debuginfo-install
python-2.7.5-48.el7.x86_64
(gdb) bt
#0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
(__P=0x7fea5c3014c0) at
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
#1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
(result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
/local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
#2  0x7fea6661d88f in
gr::filter::kernel::fir_filter_ccf::filter(std::complex const*) ()
at /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
#3  0x7fea66c01d01 in
gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector&, std::vector >&, std::vector >&) ()
at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
#4  0x7fea7b73fe10 in gr::block_executor::run_one_iteration() () at
/local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#5  0x7fea7b781120 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
at /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#6  0x7fea7b774821 in
boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::function_buffer&) () at
/local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#7  0x7fea7b725ef0 in boost::detail::thread_data::run() () at
/local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#8  0x7fea7a22427a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#9  0x7fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
#10 0x7fea9571973d in clone () at /lib64/libc.so.6
(gdb) print __P
$1 = (const float *) 0x7fea5c3014c0
(gdb) print *__P
Cannot access memory at address 0x7fea5c3014c0
(gdb) print *(__m256 *)__P
Cannot access memory at address 0x7fea5c3014c0
(gdb) f 1
#1  volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160,
input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
/local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
119 a0Val = _mm256_load_ps(aPtr);
(gdb) info locals
number = 0
sixteenthPoints = 2
res = {-1.30492652e+29, 0.0779444203}
realpt = 0x7fea57ffde50
imagpt = 0x7fea57ffde54
aPtr = 0x7fea5c3014c0
bPtr = 0x3671a00
a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127,
-0.869615495, -0.869560063, -0.887507021, -0.885902643}
a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977,
-0.0328192525, -0.0346645005, 0.376206338, 0.374125361}
a2Val = {0.711783648, 0.711464763, 0.931477308, 0.933318734, 1.01744843,
1.01973152, 0.954917312, 0.955377996}
a3Val = {0.734342158, 0.732418418, 0.374049634, 0.371605545, -0.0585254543,
-0.0588675328, -0.461206883, -0.458686352}
b0Val = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293}
b1Val = {-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193,
0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
b2Val = {0, 0, 0.22138992, 0.22138992, -0.0485430211, -0.0485430211,
-0.00614725193, -0.00614725193}
b3Val = {0.0158917159, 0.0158917159, -0.00727195293, -0.00727195293,
-0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694}
x0Val = {0.0023738991, -0.00534401694, 0.00242348039, 0.00727195293,
-0.0158917159, 0.00614725193, 0.0485430211, -0.22138992}
x1Val = {0, 0.22138992, -0.0485430211, -0.00614725193, 0.0158917159,
-0.00727195293, -0.00242348039, 0.00534401694}
x0loVal = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193}
x0hiVal = {0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293,
0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
x1loVal = {0, 0, 0.22138992, 0.22138992, 0.0158917159, 0.0158917159,
-0.00727195293, -0.00727195293}
x1hiVal = {-0.0485430211, -0.0485430211, -0.00614725193, -0.00614725193,
-0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694}
c0Val = {-0.00155906542,