In gqrx I am successfully using disconnect_all() at the top-block
level. Tonight I have tried to use it in a hier_block2 but it doesn’t
seem to work.
The relevant code snippet is here: iq_swap.cpp · GitHub - a call to
set_enabled() results in:
terminate called after throwing an instance of ‘std::invalid_argument’
what(): input port 0 out of range for complex_to_float(26)
Aborted (core dumped)
If I disconnect the blocks manually it works fine, which lead me to
believe that disconnect_all() only works at top-block level? Or maybe
a bug?
I’m using gnuradio/master from yesterday: v3.6.3-128-gbbc4da83
On Thu, Feb 21, 2013 at 2:36 PM, Alexandru C. [email protected]
wrote:
terminate called after throwing an instance of ‘std::invalid_argument’
what(): input port 0 out of range for complex_to_float(26)
Aborted (core dumped)
Can you get a gdb stack traceback on this?
If I disconnect the blocks manually it works fine, which lead me to
believe that disconnect_all() only works at top-block level? Or maybe
a bug?
On Thu, Feb 21, 2013 at 11:47 PM, Johnathan C. [email protected] wrote:
On Thu, Feb 21, 2013 at 2:36 PM, Alexandru C. [email protected] wrote:
terminate called after throwing an instance of ‘std::invalid_argument’
what(): input port 0 out of range for complex_to_float(26)
Aborted (core dumped)
Can you get a gdb stack traceback on this?
I can do that but I need some instructions.
Do I need to build gnuradio with special flags or just the usual
cmake/make?
On Thu, Feb 21, 2013 at 3:08 PM, Alexandru C. [email protected]
wrote:
Ok, I’ll do that; in gdb then I run strace or backtrace after it crashes?
$ gdb gqrx
[…]
(gdb) set args --foo --bar [if needed]
(gdb) run
[…segfault output…]
(gdb) bt
(gdb) info threads
The output from bt and info threads should tell us exactly where it is
faulting. Actually, that’s already known, its an error handler that is
throwing due to bad data, but the stack trace will tell us who was
calling
it.
On Fri, Feb 22, 2013 at 12:14 AM, Johnathan C. [email protected] wrote:
[…segfault output…]
(gdb) bt
(gdb) info threads
The output from bt and info threads should tell us exactly where it is
faulting. Actually, that’s already known, its an error handler that is
throwing due to bad data, but the stack trace will tell us who was calling
it.
I have attached the trace - I hope you can see something from it. If
Qt is interfering I can try to create a simpler example.
On Thu, Feb 21, 2013 at 3:57 PM, Alexandru C. [email protected]
wrote:
I have attached the trace - I hope you can see something from it. If
Qt is interfering I can try to create a simpler example.
Can you confirm you are linked against libgnuradio with debugging
symbols?
There are no stack frames from gnuradio between #5 and #6. This may
also
be from running inside the QT event loop, having QT absorb the
exception,
then rethrowing it.
So if you can get this to happen outside QT and verify the debug
libraries
are actually linked to, that would help.