On Fri, Apr 1, 2011 at 1:49 AM, Ron Hall <white_flag...@hotmail.com> 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: j...@joshknows.com > > To: discuss-gnuradio@gnu.org > > 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 > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
