[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] std::runtime_error (gdb backtrace included)
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] std::runtime_error (gdb backtrace included) |
Date: |
Fri, 13 Apr 2007 16:15:40 -0700 |
User-agent: |
Mutt/1.5.9i |
On Fri, Apr 13, 2007 at 03:33:46PM -0600, Tarun Tiwari wrote:
> Hi,
>
> I am implementing a relay network for voice transmision and reception. I
> using threading to start the GUI and flow graph. I am facing a runtime error
> in random at destination, whereas it works perfectly at the relay node. At
> relay node I have bypassed the audio device and have a connection like this
> :
> USRP--> gsm full rate decoder --> gsm full rate encode --> USRP.
> I ran the program in debugger mode and got following trace/errors from gdb.
> I need help from somebody to resolve this problem.
Tarun, please tell us more about the situation:
What version of GNU Radio are you using? svn or a tarball?
What OS and version are you running on?
What machine architecture?
Thanks,
Eric
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> terminate called after throwing an instance of 'std::runtime_error'
> what(): msg length is not a multiple of d_itemsize
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 145009568 (LWP 8656)]
> 0x00ef2410 in __kernel_vsyscall ()
> (gdb)
> (gdb) bt
> #0 0x00ef2410 in __kernel_vsyscall ()
> #1 0x0045fee9 in raise () from /lib/libc.so.6
> #2 0x004614f1 in abort () from /lib/libc.so.6
> #3 0x00c39780 in __gnu_cxx::__verbose_terminate_handler ()
> from /usr/lib/libstdc++.so.6
> #4 0x00c371b5 in std::set_unexpected () from /usr/lib/libstdc++.so.6
> #5 0x00c371f2 in std::terminate () from /usr/lib/libstdc++.so.6
> #6 0x00c3732a in __cxa_throw () from /usr/lib/libstdc++.so.6
> #7 0x006d3cdb in gr_message_source::work (this=0x9234d50,
> noutput_items=4095,
> address@hidden, address@hidden) at
> gr_message_source.cc:99
> #8 0x00701e1a in gr_sync_block::general_work (this=0x9234d50,
> noutput_items=4095, address@hidden, address@hidden,
> address@hidden) at gr_sync_block.cc:64
> #9 0x00700022 in gr_single_threaded_scheduler::main_loop (this=0x8d6c960)
> at gr_single_threaded_scheduler.cc:330
> #10 0x007010a1 in gr_single_threaded_scheduler::run (this=0x8d6c960)
> at gr_single_threaded_scheduler.cc:86
> #11 0x00205dab in sts_pyrun ()
> from
> /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
> #12 0x00214132 in _wrap_sts_pyrun ()
> from
> /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
> ---Type <return> to continue, or q <return> to quit---
> #13 0x47d25d2d in PyCFunction_Call () from /usr/lib/libpython2.4.so.1.0
> #14 0x47cfb587 in PyObject_Call () from /usr/lib/libpython2.4.so.1.0
> #15 0x47d5eb28 in PyEval_EvalFrame () from /usr/lib/libpython2.4.so.1.0
> #16 0x47d61638 in PyEval_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0
> #17 0x47d5f9eb in PyEval_EvalFrame () from /usr/lib/libpython2.4.so.1.0
> #18 0x47d607ac in PyEval_EvalFrame () from /usr/lib/libpython2.4.so.1.0
> #19 0x47d61638 in PyEval_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0
> #20 0x47d134ea in PyClassMethod_New () from /usr/lib/libpython2.4.so.1.0
> #21 0x47cfb587 in PyObject_Call () from /usr/lib/libpython2.4.so.1.0
> #22 0x47d01b78 in PyClass_IsSubclass () from /usr/lib/libpython2.4.so.1.0
> #23 0x47cfb587 in PyObject_Call () from /usr/lib/libpython2.4.so.1.0
> #24 0x47d5ad9c in PyEval_CallObjectWithKeywords ()
> from /usr/lib/libpython2.4.so.1.0
> #25 0x47d88c04 in initthread () from /usr/lib/libpython2.4.so.1.0
> #26 0x005a4433 in start_thread () from /lib/libpthread.so.0
> #27 0x00500a1e in clone () from /lib/libc.so.6
>
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> I googled about SIGABRT and learnt that it is sent by the process to itself
> when it calls to abort the libc function defined in stdlib.h and if the
> signal handler returns then all open streams are closed and flushed and the
> program terminates. But, I am not able to trace out where and why this
> signal handler is being called? Is there any bug with buffer/memory
> allocation?
>
> Thanks in advance.
>
> Tarun
> Multimedia Comm Lab,
> University of Texas - Dallas
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio