Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
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 11-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 freddy.15-...@freenet.de 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 11 taps. That's a gigantic filter already. At 1e9 sps, that creates a filter with 10001 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.45001, 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote: 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 11-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. 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 pgpILkUKVl4gG.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
On Mon, Nov 18, 2013 at 8:31 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote: 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 11-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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
You can find my sample Python script two posts earlier. Frederik Am 18.11.2013 14:31, schrieb Martin Braun (CEL): On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote: 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 11-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. Can you post the exact call too firdes.low_pass(), thanks. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
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: On Mon, Nov 18, 2013 at 8:31 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote: 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 11-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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing freddy.15-...@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 Am 18.11.2013 14:35, schrieb Tom Rondeau: On Mon, Nov 18, 2013 at 8:31 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote: 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 11-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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
Thank you, Tom! I will try it on my Raspi soon. Frederik Am 19.11.2013 04:38, schrieb Tom Rondeau: On Mon, Nov 18, 2013 at 9:48 AM, Tom Rondeau t...@trondeau.com wrote: On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing freddy.15-...@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 This should be fixed now. It works on my Zynq and was failing as you described previously. Tom Am 18.11.2013 14:35, schrieb Tom Rondeau: On Mon, Nov 18, 2013 at 8:31 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote: 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 11-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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
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ü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.45001, 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing freddy.15-...@freenet.de 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 11 taps. That's a gigantic filter already. At 1e9 sps, that creates a filter with 10001 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.45001, 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rational Resampler throws double free or corruption error
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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
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.45001, 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
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 On 15/11/13 11: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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error
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ü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.45001, 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
