I have a pyhton program (see
http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py)
that based on a button chooser (on/off) rearranges itself.
I use lock/unlock to do the disconnection/reconnection.
However, I always get segfaults after a couple of changes.
The graph is pretty simple:
A complex sinusodial source + noise (throttled) goes to either:
ON) multiplication by 2 and complex to mag squared
or
OFF) multiplication by 0 and complex to mag squared
and then to a null sink.
I would really appreciate some input because I am kind of lost as to
what
is going wrong.
thanks in advance,
Achilleas
Hi Achilleas,
after skimming through your code, I found no obvious mistakes so far.
My guess was that under some circumstances, you connect or disconnect a
connection twice or something similarly wicked happens, but I can’t see
why that should happen.
Can you supply us with a backtrace, generated by GDB?
(gdb --args python onoff_flat_test.py; then type “run” as soon
as gdb is ready, then type “backtrace” after the program
segfaulted)
Greetings
Marcus
Marcus,
thanks for the quick reply.
Here is the backtrace:
Sleep…
Unlocking…
[Thread 0x7fffbe7fc700 (LWP 29591) exited]
[Thread 0x7fffbf7fe700 (LWP 29593) exited]
[Thread 0x7fffdbfff700 (LWP 29595) exited]
[Thread 0x7fffe0aa7700 (LWP 29594) exited]
[Thread 0x7fffbeffd700 (LWP 29592) exited]
[Thread 0x7fffdb7fe700 (LWP 29596) exited]
[Thread 0x7fffbdffb700 (LWP 29590) exited]
[New Thread 0x7fffd8ff9700 (LWP 29603)]
[New Thread 0x7fffd97fa700 (LWP 29604)]
[New Thread 0x7fffd9ffb700 (LWP 29605)]
[New Thread 0x7fffda7fc700 (LWP 29606)]
[New Thread 0x7fffe0aa7700 (LWP 29607)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe0aa7700 (LWP 29607)]
0x00007ffff00b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 ()
from /usr/local/lib64/libvolk.so.0.0.0
==================================
(gdb) backtrace
#0 0x00007ffff00b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 ()
from /usr/local/lib64/libvolk.so.0.0.0
#1 0x00007ffff083910a in gr::blocks::multiply_const_cc_impl::work(int,
std::vector<void const*, std::allocator<void const*> >&,
std::vector<void*,
std::allocator<void*> >&) ()
from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0
#2 0x00007ffff0401fc7 in gr::sync_block::general_work(int,
std::vector<int, std::allocator >&, std::vector<void const*,
std::allocator<void const*> >&, std::vector<void*, std::allocator<void*>
&) () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#3 0x00007ffff03caca8 in gr::block_executor::run_one_iteration() ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#4 0x00007ffff0410ee6 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int)
()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#5 0x00007ffff03ff38e in gr::tpb_container::operator()() ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#6 0x00007ffff03ff58e in
gr:
:thread_body_wrappergr::tpb_container::operator()()
() from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#7 0x00007ffff03b320f in
boost::detail::thread_data<boost::function0
::run() ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#8 0x0000003349a11629 in thread_proxy () from
/lib64/libboost_thread-mt.so.1.50.0
#9 0x0000003340a07d15 in start_thread () from /lib64/libpthread.so.0
#10 0x000000333fef253d in clone () from /lib64/libc.so.6
The temporary fix suggested elsewhere with
substituting lock() with stop() followed by wait()
and unlock() with start() was tested and works fine!!!
For now this is sufficient for what I want to do,
although the stop/wait/start method
works only on the entire top_block and not on individual (hier2) blocks
as the lock/unlock (is supposed to) work
thanks everyone for the help,
Achilleas
On Fri, Oct 4, 2013 at 6:45 PM, Achilleas A.
On Mon, Oct 7, 2013 at 11:55 AM, Achilleas A.
[email protected] wrote:
Achilleas
Achilleas,
Can you open an Issues ticket for this on gnuradio.org with your
example script? I think that I might know the cause of this problem.
Just want to make sure it’s documented and doesn’t get lost.
Tom
I have uploaded a bare minimum example that still has this problem:
sinusoid–> throtle → (ON or OFF block) → null sink
http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test1.py
And here is all the output of gdb (it segfaults in unlock() ):
(gdb) backtrace
#0 0x00007ffff00b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 ()
from /usr/local/lib64/libvolk.so.0.0.0
#1 0x00007ffff083910a in gr::blocks::multiply_const_cc_impl::work(int,
std::vector<void const*, std::allocator<void const*> >&,
std::vector<void*,
std::allocator<void*> >&) ()
from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0
#2 0x00007ffff0401fc7 in gr::sync_block::general_work(int,
std::vector<int, std::allocator >&, std::vector<void const*,
std::allocator<void const*> >&, std::vector<void*, std::allocator<void*>
&) () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#3 0x00007ffff03caca8 in gr::block_executor::run_one_iteration() ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#4 0x00007ffff0410ee6 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int)
()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#5 0x00007ffff03ff38e in gr::tpb_container::operator()() ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#6 0x00007ffff03ff58e in
gr:
:thread_body_wrappergr::tpb_container::operator()()
() from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#7 0x00007ffff03b320f in
boost::detail::thread_data<boost::function0
::run() ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#8 0x0000003349a11629 in thread_proxy () from
/lib64/libboost_thread-mt.so.1.50.0
#9 0x0000003340a07d15 in start_thread () from /lib64/libpthread.so.0
#10 0x000000333fef253d in clone () from /lib64/libc.so.6
On Mon, Oct 7, 2013 at 12:10 PM, Tom R. [email protected] wrote:
thanks everyone for the help,
Achilleas
Achilleas,
Can you open an Issues ticket for this on gnuradio.org with your
example script? I think that I might know the cause of this problem.
Just want to make sure it’s documented and doesn’t get lost.
Tom
Also, make sure to record what version you’re running. I feel like I
fixed this already.
Tom