Re: [Discuss-gnuradio] std::runtime_error (gdb backtrace included)

[Eric Blossom]

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