Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error

[Tom Rondeau]

On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing <address@hidden> wrote:
> Hello again,
>
> meanwhile I got some more information about the error.
> It occurs when returning the taps from the firdes::low_pass function.
> But ONLY under some conditions.
> I wrote a simple script which is NOT working and giving the error
> mentioned earlier:
>> from gnuradio.filter import firdes
>>
>> f_s = 1e3
>> f_c = 0.2e3
>> transition_width = 100
>> low_pass1 =
>> firdes.low_pass(1,f_s,f_c,transition_width,firdes.WIN_KAISER, 5.0)
>> print len(low_pass1)
> But it does work if I change f_s to 1e6 or higher. There seems to be a
> "magic border" at 1GHz.
>
> Can anyone help me?
>
> Frederik

Not sure if you really meant 1e6 or 1 GHz (1e9).

The complexity of a filter like this is inversely proportional to the
width of the transition band. As you increase f_s, you're normalized
transition band is transition_width/f_s, which is getting smaller and
smaller.

At a sampling rate of 1 ksps, this filter you describe here is 101
taps. At 1e6 sps, you have 100001 taps. That's a gigantic filter
already. At 1e9 sps, that creates a filter with 100000001 taps. That
is, one hundred million taps.

My i7 processor with 8 GB of RAM took 30 seconds to calculate that
filter. Your RaspberryPi isn't quite that powerful. Most likely, your
running out of RAM and probably writing out of bounds, so strange
things are happening that's causing that double free.

There is absolutely no way that you need that complex of a filter.
Make sure to scale your transition width with your sampling rate.

Tom



> Am 15.11.2013 12:53, schrieb Marcus Müller:
>> Hi Frederik, hi rest,
>>
>> this is an interesting error. You might want to report it.
>> The interesting part of your backtrace is
>> #8  ~vector (this=0xbee7c59c, __in_chrg=<optimized out>)
>>     at /usr/include/c++/4.6/bits/stl_vector.h:350
>> #9  gr::filter::firdes::low_pass (gain=<optimized out>,
>>     sampling_freq=<optimized out>, cutoff_freq=0.45000000000000001,
>>     transition_width=<optimized out>, window_type=<optimized out>,
>>     beta=<optimized out>) at
>> /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
>>
>> firdes.cc:136 is the closing bracket of the for loop that iterates
>> over both the taps vector and the window vector.
>> sadly, gdb doesn't tell us whether the w or the taps vector's
>> destructor is being called.
>> As a wild guess, the compiler realised w is not being used after the
>> last iteration of the loop in the low_pass function.
>> Proposal:
>> do a
>>
>> gdb --args python top_block.py #or whatever your file is called
>> gdb>break /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
>> gdb>run
>> ##at some point, the breakpoint will be reached.
>>
>> and check if it crashes on the first run, on the last or whenever.
>>
>> Basically: It's a curious thing that this happens. I do not rule out
>> strange and wilde and generally untame things happening in memory here!
>>
>> Greetings, and look out for memory grues,
>>
>> Marcus
>>
>> On 15.11.2013 12:13, Frederik Wing wrote:
>>> Hi everyone,
>>>
>>> I am using the latest GNU Radio version compiled and running on a
>>> Raspberry Pi with Raspbian Wheezy.
>>> Most of the blocks seem to work. But the Rational Resampler makes
>>> problems.
>>>
>>> Here is my sample python script generated by GNU Radio Companion:
>>> http://pastebin.com/R0Z21MfU
>>>
>>> Running it throws the error:
>>> *** glibc detected *** /usr/bin/python2: double free or corruption
>>> (!prev): 0x02bee190 ***
>>>
>>> Debugging it with gdb gives the output here:
>>> http://pastebin.com/rXqtkZVG
>>>
>>> Any ideas how to solve this?
>>>
>>> Yours,
>>> Frederik
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio