Re: [Discuss-gnuradio] crashes, memory errors and valgrind

[Alexandru Csete]

On Mon, Jun 4, 2012 at 2:18 PM, Tom Rondeau <address@hidden> wrote:
> On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser
> <address@hidden> wrote:
>> Hi Tom,
>>
>> Tom Rondeau wrote on 2012-06-03 17:12:
>>> On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser
>>> Patrick,
>>>
>>> It looks like you're problem is in the rational_resampler code. I
>>> wonder if there's something about the resampling rate being used
>>> that's causing something to go out of bounds here. Can you dig into
>>> the code and figure out what interpolation and decimation rates are
>>> being used?
>>
>> Interpolation is 1, decimation is 2.
>>
>> I compiled GNU Radio branch v3.6.0 with
>> $ cmake -DCMAKE_BUILD_TYPE=Debug ..
>> which resulted in a compile with flags -g -O2 .
>> I tried to track what's happening in gdb, in gr_fir_fff_simd::set_taps,
>> but -O2 was not helping, a lot optimized out, loops unrolled.
>>
>> Full valgrind log in
>> http://pastebin.com/7GCs3bWy
>>
>> regards
>>
>> Patrick
>
> I was hoping you'd say the interpolation and/or decimation were some
> ridiculously large numbers. Since the block is only actually
> decimating, could you replace it in the code with an fir_filter_fff
> (or fft_filter_fff) just for testing purposes? That'll help us see if
> it's the rational resampler itself or something more general.

Patrick: You can now try my own osmosdr branch from
https://github.com/csete/gqrx
I have made many changes since I told you to stay away few days ago
and I think it is slightly usable now.

This code adds proper multirate support by using the arbitrary PFB
resamplers on both the quadrature and the audio end. It also takes
advantage of the device discovery API in gr-osmosdr so you really just
plug in your devices and go :-)

It still works very well with the Funcube Dongle and is supposed to
work with UHD devices but I really haven't had time to debug that part
yet. Gr-osmosdr source works though with UHD devices in GRC, so it's a
gqrx issue if it doesn't work.

Concerning the original topic of this thread: I can't dismiss that
it's a rarely seen bug in the GR code, but keep in mind that the fork
was made when much of my code assumed 96ksps input rate and 48ksps
audio rate.

Alex