Forum: GNU Radio Rational Resampler throws double free or corruption error

1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-15 12:18
(Received via mailing list)
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
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-11-15 12:55
(Received via mailing list)
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
E05cb2979b45c939ef802ebd4684d402?d=identicon&s=25 M Dammer (Guest)
on 2013-11-15 13:17
(Received via mailing list)
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
1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-15 20:53
(Received via mailing list)
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/repo...

Maybe you have an other idea?

Yours
Frederik

Am 15.11.2013 12:53, schrieb Marcus Mller:
1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-17 15:42
(Received via mailing list)
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 Mller:
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-11-17 17:49
(Received via mailing list)
On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing
<freddy.15-etc@freenet.de> 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
1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-18 14:24
(Received via mailing list)
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 Rondeau:
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-11-18 14:32
(Received via mailing list)
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 Braun
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
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-11-18 14:36
(Received via mailing list)
On Mon, Nov 18, 2013 at 8:31 AM, Martin Braun (CEL)
<martin.braun@kit.edu> 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
1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-18 14:41
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-18 14:45
(Received via mailing list)
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 Rondeau:
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-11-18 15:50
(Received via mailing list)
On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing
<freddy.15-etc@freenet.de> 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
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-11-19 04:39
(Received via mailing list)
On Mon, Nov 18, 2013 at 9:48 AM, Tom Rondeau <tom@trondeau.com> wrote:
> Tom
This should be fixed now. It works on my Zynq and was failing as you
described previously.

Tom
1da22fe7e673c2f376096fbe74b66fbc?d=identicon&s=25 Frederik Wing (Guest)
on 2013-11-19 08:49
(Received via mailing list)
Thank you, Tom!
I will try it on my Raspi soon.

Frederik

Am 19.11.2013 04:38, schrieb Tom Rondeau:
This topic is locked and can not be replied to.