Rational Resampler throws double free or corruption error

GNU Radio
1

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:

Running it throws the error:
*** glibc detected *** /usr/bin/python2: double free or corruption
(!prev): 0x02bee190 ***

Debugging it with gdb gives the output here:

Any ideas how to solve this?

Yours,
Frederik

2

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=)
at /usr/include/c++/4.6/bits/stl_vector.h:350
#9 gr::filter::firdes::low_pass (gain=,
sampling_freq=, cutoff_freq=0.45000000000000001,
transition_width=, window_type=,
beta=) 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

3

I pulled and compiled the latest gnuradio yesterday on an intel machine.
My project uses the rational resampler as well and I am having no
problems.
Mark

4

Good evening Marcus,

thanks for your fast response.

In my sources firdes.cc:136 is

return taps;
I cloned them from the git repository. Here is the source of the
trouble-making file:
http://gnuradio.org/redmine/projects/gnuradio/repository/entry/gr-filter/lib/firdes.cc?rev=master

Maybe you have an other idea?

Yours
Frederik

Am 15.11.2013 12:53, schrieb Marcus M.:

5

On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing
[email protected] wrote:

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

6

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

Am 15.11.2013 12:53, schrieb Marcus M.:

7

Hi Tom,

what you are writing is completely right. Simply increasing the sampling
frequency will result in a more complex filter.

Nevertheless the firdes.low_pass function does NOT want to calculate the
101-tap-filter. But it DOES calculate the 100001-tap-filter. Really
strange. So this might not be a memory problem.

The “magic border” I described is at 1MHz. Not at 1GHz as I wrote
accidentally.

Do you have another idea what the problem could be?

Frederik

Am 17.11.2013 17:48, schrieb Tom R.:

8

On Mon, Nov 18, 2013 at 8:31 AM, Martin B. (CEL)
[email protected] wrote:

The “magic border” I described is at 1MHz. Not at 1GHz as I wrote
accidentally.

Can you post the exact call too firdes.low_pass(), thanks.

MB

Yes, Frederik, I’m afraid you’re not being clear. You say you can’t
build a 101 tap filter? That’s different than what you were saying
before. Are you saying that you can’t go below 1e6 sps or above it?

Tom

9

On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote:

accidentally.
Can you post the exact call too firdes.low_pass(), thanks.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

10

As I said, I cannot design a filter with a sampling frequency below 1e6.
The Python script I posted (where f_s = 1e3) does NOT work! But if I
change f_s to 1e6 it works and gives me the gigantic filter.

Frederik

Am 18.11.2013 14:35, schrieb Tom R.:

11

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

12

On Mon, Nov 18, 2013 at 9:48 AM, Tom R. [email protected] wrote:

Tom
This should be fixed now. It works on my Zynq and was failing as you
described previously.

Tom

13

Thank you, Tom!
I will try it on my Raspi soon.

Frederik

Am 19.11.2013 04:38, schrieb Tom R.:

14

On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing
[email protected] wrote:

As I said, I cannot design a filter with a sampling frequency below 1e6.
The Python script I posted (where f_s = 1e3) does NOT work! But if I
change f_s to 1e6 it works and gives me the gigantic filter.

Frederik

I think I see the problem. Testing now. Not sure why this works on
Intel machines without throwing, actually.

Tom