Forum: GNU Radio std::runtime_error (gdb backtrace included)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D900623ccc37337676f54c97a3586969?d=identicon&s=25 Tarun Tiwari (Guest)
on 2007-04-13 23:35
(Received via mailing list)
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.

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
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,
    input_items=@0x8a49880, output_items=@0x8a49874) at
gr_message_source.cc:99
#8  0x00701e1a in gr_sync_block::general_work (this=0x9234d50,
    noutput_items=4095, ninput_items=@0x8a4988c, input_items=@0x8a49880,
    output_items=@0x8a49874) 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
D900623ccc37337676f54c97a3586969?d=identicon&s=25 Tarun Tiwari (Guest)
on 2007-04-13 23:38
(Received via mailing list)
Hi,
I recieved the same error at my relay node too and it was for the first
time.
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-04-14 01:11
(Received via mailing list)
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



> #1  0x0045fee9 in raise () from /lib/libc.so.6
> #8  0x00701e1a in gr_sync_block::general_work (this=0x9234d50,
>   from
> #21 0x47cfb587 in PyObject_Call () from /usr/lib/libpython2.4.so.1.0
> 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
D900623ccc37337676f54c97a3586969?d=identicon&s=25 Tarun Tiwari (Guest)
on 2007-04-14 02:59
(Received via mailing list)
On 4/13/07, Eric Blossom <eb@comsec.com> wrote:
>
> >On Fri, Apr 13, 2007 at 03:33:46PM -0600, Tarun Tiwari wrote:
>
> >Tarun, please tell us more about the situation:
>
> >What version of GNU Radio are you using?  svn or a tarball?


 I am running the latest developement codes downloaded from svn.

>What OS and version are you running on?


On relay node I am using FC4 and on destination node I am using FC5.

>What machine architecture?


1) The relay node have following  architechure:

x86:
Family: 15 Model: 1 Stepping: 2 Type: 0 Brand: 8
CPU Model: Pentium 4 (Willamette) [D0] Original OEM
Processor name string: Intel(R) Pentium(R) 4 CPU 1.80GHz
Instruction trace cache:  Size: 12K uOps  8-way associative.
L1 Data cache:    Size: 8KB       Sectored, 4-way associative.  line
size=64
bytes.
L2 unified cache:  Size: 256KB     Sectored, 8-way associative.  line
size=64 bytes.
Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 64 entries.
Data TLB: 4KB or 4MB pages, fully associative, 64 entries.
RAM:    514820 kB

2) The Destination node has following architecture:

intel Duo Core T2300 @ 1.66GHz
Family: 6 Model: 14 Stepping: 8
Cache: 2MB
RAM : 1GB

>Thanks,
> >Eric


Thanks,
Tarun
Multimedia Comm Lab,
University of Texas - Dallas
D900623ccc37337676f54c97a3586969?d=identicon&s=25 Tarun Tiwari (Guest)
on 2007-04-16 19:24
(Received via mailing list)
Hi Eric,

Thanks for your time.
Any suggestions on this issue?

---------- Forwarded message ----------
From: Tarun Tiwari <tarunmani@gmail.com>
Date: Apr 13, 2007 7:58 PM
Subject: Re: [Discuss-gnuradio] std::runtime_error (gdb backtrace
included)
To: Eric Blossom <eb@comsec.com>
Cc: discuss-gnuradio@gnu.org



On 4/13/07, Eric Blossom <eb@comsec.com> wrote:
>
> >On Fri, Apr 13, 2007 at 03:33:46PM -0600, Tarun Tiwari wrote:
>
> >Tarun, please tell us more about the situation:
>
> >What version of GNU Radio are you using?  svn or a tarball?


 I am running the latest developement codes downloaded from svn.

>What OS and version are you running on?


On relay node I am using FC4 and on destination node I am using FC5.

>What machine architecture?


1) The relay node have following  architechure:

x86:
Family: 15 Model: 1 Stepping: 2 Type: 0 Brand: 8
CPU Model: Pentium 4 (Willamette) [D0] Original OEM
Processor name string: Intel(R) Pentium(R) 4 CPU 1.80GHz
Instruction trace cache:  Size: 12K uOps  8-way associative.
L1 Data cache:    Size: 8KB       Sectored, 4-way associative.  line
size=64
bytes.
L2 unified cache:  Size: 256KB     Sectored, 8-way associative.  line
size=64 bytes.
Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 64 entries.
Data TLB: 4KB or 4MB pages, fully associative, 64 entries.
RAM:    514820 kB

2) The Destination node has following architecture:

intel Duo Core T2300 @ 1.66GHz
Family: 6 Model: 14 Stepping: 8
Cache: 2MB
RAM : 1GB

>Thanks,
> >Eric


Thanks,
Tarun
Multimedia Comm Lab,
University of Texas - Dallas
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-04-16 21:52
(Received via mailing list)
On Fri, Apr 13, 2007 at 03:33:46PM -0600, Tarun Tiwari wrote:
>
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> terminate called after throwing an instance of 'std::runtime_error'
>  what():  msg length is not a multiple of d_itemsize

Hi Tarun,

The exception indicates that you sent gr_message_source a message
that wasn't a multiple of the itemsize that you specified in the
constructor.  See line 99 in gr_message_source.cc

How are you calling it?

FYI, I looked at the old
gnuradio-examples/python/digital_voice/encdec.py
code, but it's suffered bit rot and was never updated to use the the
revised packet based modulators.  It would take some work to
straighten it out, and I don't have time to pursue that now.

Eric


> #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,
>    input_items=@0x8a49880, output_items=@0x8a49874) at
> gr_message_source.cc:99

... This is where the problem is ...

> #12 0x00214132 in _wrap_sts_pyrun ()
>   from
> /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so


Eric
This topic is locked and can not be replied to.