discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] FPE with FM Rcvr


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] FPE with FM Rcvr
Date: Fri, 1 Apr 2011 09:36:40 -0400

On Fri, Apr 1, 2011 at 1:49 AM, Ron Hall <address@hidden> wrote:
Adding to the following, a backtrace that points to the throw std::bad_alloc (), gr_buffer.cc (88)

May have some association with another error addressed earlier this year by T. Rondeau: [Discuss-gnuradio] gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument, Dated: Fri, 11 Feb 2011 09:52:04-0500


Ron, I took a look at your graph, and I see a few discrepancies. Where are you getting your numbers for adc_rate, usrp_dec, and usrp_inter? Using a sample rate for the USRP as 3.2 Msps doesn't work because it runs at 100 Msps with integer decimation, so you are really asking for a decimation of 31.25. Instead, it is giving you a decimation of 31 for a rate of 3.225, as the warning in your original email said.

I then don't quite get what you are doing with the rational resampler and how you are building the taps for the frequency translating filter, but maybe I just haven't gone through the math properly.

Importantly, though, you have set the decimation of the filter to 0 (probably because you are doing integer division with audio_inter/audio_dec, which is less than 1; I suspect you meant audio_rate/audio_dec or something), which, while I haven't tested it, is probably where you're problem is.


gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument
gr_buffer::allocate_buffer: failed to allocate buffer of size 18760 KB
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc


Program received signal SIGABRT, Aborted.
0x00436416 in __kernel_vsyscall ()
(gdb) bt
#0  0x00436416 in __kernel_vsyscall ()
#1  0x006c2941 in raise () from /lib/libc.so.6
#2  0x006c5e42 in abort () from /lib/libc.so.6
#3  0x008a3055 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#4  0x008a0f35 in ?? () from /usr/lib/libstdc++.so.6
#5  0x008a0f72 in std::terminate() () from /usr/lib/libstdc++.so.6
#6  0x008a10e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0x00ae4861 in gr_buffer::gr_buffer (this=0xb4ef478, nitems=2345, sizeof_item=8192, link=...) at gr_buffer.cc:88

You are asking for a huge buffer here. It's throwing because it can't properly allocate you the size buffer you are requesting. It's seeking a buffer of 2345 items with a size of 8192 for each item. I'm not sure which block is doing this, but it strikes me it could be due to the decimation of 0 in the filter.

Tom


 
#8  0x00ae4908 in gr_make_buffer (nitems=2345, sizeof_item=8192, link=...) at gr_buffer.cc:96
#9  0x00acec5f in gr_flat_flowgraph::allocate_buffer (this=0xb4ef458, block=..., port=0) at gr_flat_flowgraph.cc:121
#10 0x00acf1af in gr_flat_flowgraph::allocate_block_detail (this=0xb4ef458, block=...) at gr_flat_flowgraph.cc:80
#11 0x00ad1538 in gr_flat_flowgraph::setup_connections (this=0xb4ef458) at gr_flat_flowgraph.cc:62
#12 0x00af7880 in gr_top_block_impl::start (this=0xab2dcd0) at gr_top_block_impl.cc:106
#13 0x00af61b0 in gr_top_block::start (this=0xaa91c78) at gr_top_block.cc:59
#14 0x00179128 in _wrap_gr_top_block_sptr_start (args=0xa7bdeec) at python/gnuradio_core_runtime.cc:15301
#15 0x080ddd23 in PyEval_EvalFrameEx ()
#16 0x080df04c in PyEval_EvalFrameEx ()
#17 0x080df04c in PyEval_EvalFrameEx ()
#18 0x080dfbb2 in PyEval_EvalCodeEx ()
#19 0x080de145 in PyEval_EvalFrameEx ()
#20 0x080dfbb2 in PyEval_EvalCodeEx ()
#21 0x080dfca7 in PyEval_EvalCode ()
#22 0x080fd956 in PyRun_FileExFlags ()
#23 0x080d7d09 in ?? ()
#24 0x080ddd23 in PyEval_EvalFrameEx ()
#25 0x080dfbb2 in PyEval_EvalCodeEx ()
#26 0x080dfca7 in PyEval_EvalCode ()
#27 0x080fe460 in PyRun_StringFlags ()
#28 0x080dee04 in PyEval_EvalFrameEx ()
#29 0x080dfbb2 in PyEval_EvalCodeEx ()
#30 0x080de145 in PyEval_EvalFrameEx ()
#31 0x080df04c in PyEval_EvalFrameEx ()
#32 0x080df04c in PyEval_EvalFrameEx ()
#33 0x080dfbb2 in PyEval_EvalCodeEx ()
#34 0x080dfca7 in PyEval_EvalCode ()
#35 0x080df0d8 in PyEval_EvalFrameEx ()
#36 0x080dfbb2 in PyEval_EvalCodeEx ()
#37 0x080de145 in PyEval_EvalFrameEx ()
#38 0x080dfbb2 in PyEval_EvalCodeEx ()
#39 0x08168e3c in ?? ()
#40 0x0805fd6a in PyObject_Call ()
#41 0x0805aa53 in ?? ()
#42 0x0805b295 in Py_Main ()
#43 0x0805a8ab in main ()
(gdb)



> Date: Wed, 30 Mar 2011 22:25:42 -0700
> From: address@hidden
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] FPE with FM Rcvr

>
>
>
> On 03/30/2011 09:31 PM, Ron Hall wrote:
> >
> > Working the following issue...any ideas?
> >
> > System: Ubuntu 10.10, Gnuradio 3.3.0, uhd (Mar 2011), USRP2, TVRX
> >
> > Using the attached grc model results in a floating point exception:
> >
> >
>
> (process of elimination)
>
> it looks like its coming from the xlating filter
>
>
> > It might be a memory issue. An attempt to sample at the 6Mz limit
> > with the TVRX (board responds with ~5.88...) results in
> > gr_buffer:allocate_buffer: failed to allocate buffer of size 18760,
> > which points to an installation issue that make check should have
> > handled...a reinstall and closer scrutiny of the output should
> > highlight any neglected warnings/errors.
> >
> >
>
> failed to allocate is an issue introduced by a block that changed that
> is used in the fft sink (tom?)
>
> -Josh
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

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