[Discuss-gnuradio] Segfault in Polyphase clock sync block

[Daniel Estévez]

Hi all,

I'm using a Polyphase clock sync block in one of my flowgraphs
(https://github.com/daniestevez/gr-satellites/blob/master/apps/picsat.grc)
and I'm getting a segmentation fault when running the flowgraph.

Using GDB, the problem seems to be in the Polyphase clock
implementation, when filtering is done via fir_filter_ccf (see the
backtrace below).

I've studied a bit pfb_clock_sync_ccf_impl::general_work() and I have
the impression that the line

out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);

might run into problems if there are not enough samples in the input
buffer, since filter() assumes you pass as many samples as taps are in
the filter.

The pfb_clock_sync_ccf_impl::general_work() doesn't ever look at
ninput_items to check how much output can be produced with the input
given, so I'm not even sure how it manages to run correctly in many
other cases (I've had no problems with Polyphase clock in many other
flowgraphs).

Regards,

Daniel.

-----------
BACKTRACE


#0 volk_32fc_32f_dot_prod_32fc_a_avx (result=0x555556735100,
input=<optimized out>, taps=0x55555673c5a0, num_points=89)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:138
#1 0x00007fffe9b61119 in gr::filter::kernel::fir_filter_ccf::filter
(this=0x555556734f00, input=***@entry=0x7fffa4804d80)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/gr-filter/lib/fir_filter.cc:232
#2 0x00007fffea15266b in
gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x555556730080,
noutput_items=16, ninput_items=..., input_items=...,
output_items=std::vector of length 1, capacity 1 = {...}) at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/gr-digital/lib/pfb_clock_sync_ccf_impl.cc:465
#3 0x00007ffff5d48608 in gr::block_executor::run_one_iteration
(this=***@entry=0x7fffbeffcdd0)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/gnuradio-runtime/lib/block_executor.cc:451
#4 0x00007ffff5d927c8 in gr::tpb_thread_body::tpb_thread_body
(this=0x7fffbeffcdd0, block=..., start_sync=...,
max_noutput_items=<optimized out>)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/gnuradio-runtime/lib/tpb_thread_body.cc:123
#5 0x00007ffff5d86ac4 in gr::tpb_container::operator() (this=<optimized
out>, this=<optimized out>, this=<optimized out>, this=<optimized out>)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/gnuradio-runtime/lib/scheduler_tpb.cc:46
#6 gr::thread::thread_body_wrapper<gr::tpb_container>::operator()
(this=0x555556776120)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
#7
boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>,
void>::invoke (function_obj_ptr=...)
at /usr/include/boost/function/function_template.hpp:159
#8 0x00007ffff5d33f42 in boost::function0<void>::operator()
(this=<optimized out>) at
/usr/include/boost/function/function_template.hpp:771
#9 boost::detail::thread_data<boost::function0<void> >::run
(this=<optimized out>) at /usr/include/boost/thread/detail/thread.hpp:116
#10 0x00007ffff4a9994d in ?? () from /usr/lib64/libboost_thread.so.1.63.0
#11 0x00007ffff77de677 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff751ec7f in clone () from /lib64/libc.so.6

[Sakthivel Velumani]

Hi Daniel,

The pfb block sets history() to ensure sufficient amount of input items are
available. Can you provide information on arguments passed to the pfb block
like sps, taps and no. of filters?

Best,
Sakthivel

Post by Daniel Estévez
Hi all,
I'm using a Polyphase clock sync block in one of my flowgraphs
(https://github.com/daniestevez/gr-satellites/blob/master/apps/picsat.grc)
and I'm getting a segmentation fault when running the flowgraph.
Using GDB, the problem seems to be in the Polyphase clock
implementation, when filtering is done via fir_filter_ccf (see the
backtrace below).
I've studied a bit pfb_clock_sync_ccf_impl::general_work() and I have
the impression that the line
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);
might run into problems if there are not enough samples in the input
buffer, since filter() assumes you pass as many samples as taps are in
the filter.
The pfb_clock_sync_ccf_impl::general_work() doesn't ever look at
ninput_items to check how much output can be produced with the input
given, so I'm not even sure how it manages to run correctly in many
other cases (I've had no problems with Polyphase clock in many other
flowgraphs).
Regards,
Daniel.
-----------
BACKTRACE
#0 volk_32fc_32f_dot_prod_32fc_a_avx (result=0x555556735100,
input=<optimized out>, taps=0x55555673c5a0, num_points=89)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:138
#1 0x00007fffe9b61119 in gr::filter::kernel::fir_filter_ccf::filter
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
gr-filter/lib/fir_filter.cc:232
#2 0x00007fffea15266b in
gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x555556730080,
noutput_items=16, ninput_items=..., input_items=...,
output_items=std::vector of length 1, capacity 1 = {...}) at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
gr-digital/lib/pfb_clock_sync_ccf_impl.cc:465
#3 0x00007ffff5d48608 in gr::block_executor::run_one_iteration
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
gnuradio-runtime/lib/block_executor.cc:451
#4 0x00007ffff5d927c8 in gr::tpb_thread_body::tpb_thread_body
(this=0x7fffbeffcdd0, block=..., start_sync=...,
max_noutput_items=<optimized out>)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
gnuradio-runtime/lib/tpb_thread_body.cc:123
#5 0x00007ffff5d86ac4 in gr::tpb_container::operator() (this=<optimized
out>, this=<optimized out>, this=<optimized out>, this=<optimized out>)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
gnuradio-runtime/lib/scheduler_tpb.cc:46
#6 gr::thread::thread_body_wrapper<gr::tpb_container>::operator()
(this=0x555556776120)
at
/usr/src/debug/net-wireless/gnuradio-9999/gnuradio-9999/
gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
#7
thread::thread_body_wrapper<gr::tpb_container>,
void>::invoke (function_obj_ptr=...)
at /usr/include/boost/function/function_template.hpp:159
#8 0x00007ffff5d33f42 in boost::function0<void>::operator()
(this=<optimized out>) at
/usr/include/boost/function/function_template.hpp:771
#9 boost::detail::thread_data<boost::function0<void> >::run
(this=<optimized out>) at /usr/include/boost/thread/detail/thread.hpp:116
#10 0x00007ffff4a9994d in ?? () from /usr/lib64/libboost_thread.so.1.63.0
#11 0x00007ffff77de677 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff751ec7f in clone () from /lib64/libc.so.6
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Daniel Estévez]

Post by Sakthivel Velumani
Hi Daniel,
The pfb block sets history() to ensure sufficient amount of input items
are available. Can you provide information on arguments passed to the
pfb block like sps, taps and no. of filters?

Hi Sakthivel,

The parameters I'm using in the PFB are:

samp_per_sym = 8
nfilts = 16

Samples/Symbol = 8
Loop Bandwidth = 1
Taps = firdes.root_raised_cosine(nfilts, nfilts,
1.0/float(samp_per_sym), 0.35, 11*samp_per_sym*nfilts)
Filter size = nfilts
Initial phase = nfilts/2
Maximum rate deviation = 0.05
Output SPS = 1

Regards,

Daniel.

[Daniel Estévez]

Post by Daniel Estévez
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);

Hi all,

I've been looking at this again and the problem is that in this line,

count = -134217704

for some weird reason. Obviously, this causes the SIGSEGV.

I'll try to see why count gets corrupted.

Regards,

Daniel.

[Daniel Estévez]

Post by Daniel Estévez

Post by Daniel Estévez
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);

Hi all,
I've been looking at this again and the problem is that in this line,
count = -134217704
for some weird reason. Obviously, this causes the SIGSEGV.
I'll try to see why count gets corrupted.

Hi again,

Problem solved. The cause was that before the PFB I had an AGC block
that when feeding it a stream of 0's, it was performing 0/0 and so
feeding a stream of nan's into the PFB.

This makes all the loop calculations propagate the nan and all loop
variables end up being nan, including d_k. Then, the line 449 in
pfb_clock_sync_ccf_impl.cc, does

d_filtnum = (int)floor(d_k);

and since d_filtnum is an integer and after this line it is adjusted to
the range [0, d_nfilters], modifying the count in the process, this
causes count to become some weird value.

So the problem was not with the PFB but with my previous block. However,
I think that the PFB should have some protection against this.

Regards,

Daniel.

[Jeff Long]

The forecast function is supposed to guarantee that there is enough
input, but it might be rounding down in some cases. Could you try
adding the "+1" to the last line and see if that changes anything?


void
pfb_clock_sync_ccf_impl::forecast(int noutput_items,
gr_vector_int &ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = (noutput_items + history()) * (d_sps/d_osps) + 1;
}

Post by Daniel Estévez

Post by Daniel Estévez
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);

Hi all,
I've been looking at this again and the problem is that in this line,
count = -134217704
for some weird reason. Obviously, this causes the SIGSEGV.
I'll try to see why count gets corrupted.
Regards,
Daniel.
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Jeff Long]

Ah, good. I didn't think it needed another +1 but couldn't think of any
other overflow.

The forecast function is supposed to guarantee that there is enough input, but it might be rounding down in some cases. Could you try adding the "+1" to the last line and see if that changes anything?
void
pfb_clock_sync_ccf_impl::forecast(int noutput_items,
gr_vector_int &ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = (noutput_items + history()) * (d_sps/d_osps) + 1;
}

Post by Daniel Estévez

Post by Daniel Estévez
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);

Hi all,
I've been looking at this again and the problem is that in this line,
count = -134217704
for some weird reason. Obviously, this causes the SIGSEGV.
I'll try to see why count gets corrupted.
Regards,
Daniel.
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Jeff Long]

Added issue https://github.com/gnuradio/gnuradio/issues/1554

Post by Jeff Long
Ah, good. I didn't think it needed another +1 but couldn't think of any
other overflow.

The forecast function is supposed to guarantee that there is enough input, but it might be rounding down in some cases. Could you try adding the "+1" to the last line and see if that changes anything?
void
pfb_clock_sync_ccf_impl::forecast(int noutput_items,
gr_vector_int &ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = (noutput_items + history()) * (d_sps/d_osps) + 1;
}

Post by Daniel Estévez

Post by Daniel Estévez
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);

Hi all,
I've been looking at this again and the problem is that in this line,
count = -134217704
for some weird reason. Obviously, this causes the SIGSEGV.
I'll try to see why count gets corrupted.
Regards,
Daniel.
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio