Any general clues what would be causing:
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int, unsigned int): Assertion `s < d_bufsize’ failed.
I’m taking a closer look at atsc_bit_timing_loop.cc|h and trying
gr_sync_decimator in place of gr_sync_block, however that error occurs
with both. It is supposed to be a decimator since the rf in at sample
rate 20e6 and symbols out at 10.76MHz.
Putting in the history=1500 and printing ninput_items_required gets
this:
gr_fir_fff: using SSE
ninput_items_required: 16720
ninput_items_required: 9108
ninput_items_required: 5303
ninput_items_required: 3400
ninput_items_required: 2448
ninput_items_required: 1972
ninput_items_required: 1735
ninput_items_required: 1616
ninput_items_required: 1556
ninput_items_required: 1526
ninput_items_required: 1512
ninput_items_required: 1504
ninput_items_required: 1500
ninput_items_required: 8597
ninput_items_required: 5048
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int, unsigned int): Assertion `s < d_bufsize’ failed.
–Chuck
On Mon, May 01, 2006 at 12:08:57PM -0400, Chuck Swiger wrote:
Any general clues what would be causing:
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int, unsigned int): Assertion `s < d_bufsize’ failed.
You’re probably returning a value from work/general_work that’s
greater than nouput_items. Add an assert to you code.
I’m taking a closer look at atsc_bit_timing_loop.cc|h and trying
gr_sync_decimator in place of gr_sync_block, however that error occurs
with both. It is supposed to be a decimator since the rf in at sample
rate 20e6 and symbols out at 10.76MHz.
It needs to subclass gr_block since it isn’t exactly N:1.
Eric
On Mon, 2006-05-01 at 10:38 -0700, Eric B. wrote:
You’re probably returning a value from work/general_work that’s
greater than nouput_items. Add an assert to you code.
Indeed - an fprintf shows:
ninput_items_required: 8597
ninput_items_required: 5048
noutput_items: 1910, Returning k: 15643440 <==== WOW
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int, unsigned int): Assertion `s < d_bufsize’ failed.
It needs to subclass gr_block since it isn’t exactly N:1.
Yikes.
On Mon, 2006-05-01 at 10:38 -0700, Eric B. wrote:
On Mon, May 01, 2006 at 12:08:57PM -0400, Chuck Swiger wrote:
Any general clues what would be causing:
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int, unsigned int): Assertion `s < d_bufsize’ failed.
You’re probably returning a value from work/general_work that’s
greater than nouput_items. Add an assert to you code.
Look like the old code has a flaw:
for (int k = 0; k < noutput_items; k++){
…
out_sample[k] = interp_sample;
…
}
return k;
but modern compilers deallocate the index when the loop
is completed (one web page says), so the fix is to use:
for (int k = 0; k < noutput_items; k++){
…
out_sample[k] = interp_sample;
…
}
return noutput_items;
On Mon, May 01, 2006 at 06:02:29PM -0400, Chuck Swiger wrote:
Look like the old code has a flaw:
for (int k = 0; k < noutput_items; k++){
…
out_sample[k] = interp_sample;
…
}
return k;
Agreed
return noutput_items;
As long as there’s no early exit from the loop 
Otherwise:
int k = 0;
for (k = 0; k < noutput_items; k++){
…
out_sample[k] = interp_sample;
…
}
return k;
Quoting C. Swiger [email protected]:
}
return noutput_items;
In fact, modern compilers should produce an error on such code since k
is used
outside of its declared scope, e.g.
cat test.c
int main() {
for (int i = 0; i < 5; i++) {
printf(“%d\n”, i);
}
printf(“%d\n”, i);
return 0;
}
gcc -o test ./test.c
test.c: In function main': test.c:2: error: for’ loop initial declaration used outside C99 mode
g++ -o test ./test.c
test.c: In function int main()': test.c:7: error: name lookup of i’ changed for new ISO for' scoping test.c:4: error: using obsolete binding at i’
gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2)
(the compilers I’ve tested, 3.3, 3.4, 4.0 all give this error.)
Now, you could pass gcc enough flags to make it accept that code (e.g.
tell it
to not use C99 mode)… but you really shouldn’t do that.
On Mon, 2006-05-01 at 15:05 -0700, Eric B. wrote:
return noutput_items;
}
return k;
That’s the correct fix - the “int k = 0” above was a self inflicted
wound as there was already an “unsigned int k” declared outside the
loop.
IANAC++P
With that fix in place, data appears from the equalizer and field sync
demux is searching for sync.
–Chuck