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 Anastasopoulos
<anas...@umich.edu>wrote:

> 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<int> >&, 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_ptr<gr::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::thread_body_wrapper<gr::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<void> >::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 Fri, Oct 4, 2013 at 6:00 PM, Marcus Müller <mar...@hostalia.de> wrote:
>
>> 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<return>" as soon
>> as gdb is ready, then type "backtrace<return>" after the program
>> segfaulted)
>>
>> Greetings
>> Marcus
>> On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote:
>> >
>> >
>> > 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
>> >
>> >
>> > _______________________________________________
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to