discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Frederik Wing
Subject: Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
Date: Mon, 18 Nov 2013 14:19:55 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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:
> 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
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]