# Sync\_decimator\_ff block with decimation above 262144 gives segfault

**URL:** <https://www.ruby-forum.com/t/sync-decimator-ff-block-with-decimation-above-262144-gives-segfault/234185>\
**Category:** GNU Radio\
**Created:** [February 12, 2015, 11:16pm UTC](https://www.ruby-forum.com/t/sync-decimator-ff-block-with-decimation-above-262144-gives-segfault/234185 "2015-02-12T23:16:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [February 12, 2015, 11:16pm UTC](https://www.ruby-forum.com/t/sync-decimator-ff-block-with-decimation-above-262144-gives-segfault/234185/1 "2015-02-12T23:16:17Z")

</div>

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(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

---

<div class="post-metadata">

**Author:** ![martin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/73ab20/32.png) [@martin](https://www.ruby-forum.com/u/martin)\
**Post date:** [February 17, 2015, 5:35pm UTC](https://www.ruby-forum.com/t/sync-decimator-ff-block-with-decimation-above-262144-gives-segfault/234185/2 "2015-02-17T17:35:13Z")

</div>

On Thu, Feb 12, 2015 at 5:14 PM, Martin [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> The blocks seem to be are accessing the input buffer outside the valid  
> creating the buffers.  
> int multiple = dgrblock-\>output\_multiple();  
> 53 gr\_vector\_void\_star &output\_items)
> 
> 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](http://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