discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] sync_decimator_ff block with decimation above 262


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] sync_decimator_ff block with decimation above 262144 gives segfault
Date: Tue, 17 Feb 2015 11:33:24 -0500

On Thu, Feb 12, 2015 at 5:14 PM, Martin <address@hidden> wrote:
Hi all,

When I set the decimation of a fir_filter or integrate block with float input and output to 262144 or above, gnuradio crashes with a segfault.
With complex inputs and outputs I get a segfault above 524288.
with short inputs and outputs it is at decimation 131072.

This seems to be the case with most (all) sync_decimator blocks like fir_filters or the integration block.

The blocks seem to be are accessing the input buffer outside the valid range. Which indicates that the input buffers are too small.

What is strange is that if the datatype is 2 times as large  (float = 4 bytes, complex = 8 bytes) the decimation factor may also be 2 times larger, which indicates that the problem occurs at a bufferposition that is 2x2 = 4 times larger.
So the buffersize does not seem to be fixed.


The required buffersizes should be automatically calculated before creating the buffers.
Are all buffers still calculated and instantiated in flat_flowgraph.cc ?

I could not yet find any obvious errors in calculating the required buffer sizes. But something is going wrong.

The buffersize calculation in flat_flowgraph.cc :
flat_flowgraph::allocate_buffer(basic_block_sptr block, int port) {
...
...
double decimation = (1.0/dgrblock->relative_rate());
int multiple      = dgrblock->output_multiple();
int history       = dgrblock->history();
nitems = std::max(nitems, static_cast<int>(2*(decimation*multiple+history)));


When using the integration_ff block gdb debug shows that the segfault is at line 61 of integrate_ff_impl.cc

51    integrate_ff_impl::work(int noutput_items,
52                    gr_vector_const_void_star &input_items,
53                    gr_vector_void_star &output_items)
54    {
55      const float *in = (const float *)input_items[0];
56      float *out = (float *)output_items[0];
57
58      for (int i = 0; i < noutput_items; i++) {
59      out[i] = (float)0;
60      for (int j = 0; j < d_decim; j++)
61        out[i] += in[i*d_decim+j];//<== segfault here !!!
62      }


gnuradio-config-info -v
3.7.7git-0-gf0cd5041

With best regards,

Martin Dudok van Heel

Hi Martin,

Thanks for pointing this out. Could you please open this up as an Issue on our issue tracker on gnuradio.org? Otherwise, this email and information are likely to get lost and forgotten about before we can do anything about it.

Now, doing that level of decimation is kind of crazy, which is why it's taken over 10 years to find this bug. Still, it shouldn't segfault on it even if the scheduler can't handle those numbers. This is almost certainly related to the max buffer size.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]