discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Lock/Unlock segfaulting


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Lock/Unlock segfaulting
Date: Mon, 7 Oct 2013 12:10:53 -0400

On Mon, Oct 7, 2013 at 12:10 PM, Tom Rondeau <address@hidden> wrote:
> On Mon, Oct 7, 2013 at 11:55 AM, Achilleas Anastasopoulos
> <address@hidden> wrote:
>> 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
>
> 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



>> On Fri, Oct 4, 2013 at 6:45 PM, Achilleas Anastasopoulos <address@hidden>
>> 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 <address@hidden> 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
>>>> > address@hidden
>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]