discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] "Run to completion" not working with message pass


From: Piotr Krysik
Subject: Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
Date: Sat, 04 Apr 2015 12:30:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

W dniu 03.04.2015 o 13:25, Piotr Krysik pisze:
> W dniu 02.04.2015 o 15:30, Piotr Krysik pisze:
>> W dniu 01.04.2015 o 12:10, Marcus Müller pisze:
>>> Hi  Piotr,
>>>
>>> nice to hear you got a step ahead!
>>> so,
>>>> I did that and what I obtained was:
>>>> ---------------------------------------------------------------------------------------
>>>>   16   Thread 0x7fffbdffb700 (LWP 13462) "python"
>>>> pthread_cond_wait@@GLIBC_2.3.2 () at
>>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>>>>   3    Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1"
>>>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>>> * 1    Thread 0x7ffff7fc7740 (LWP 13444) "python" 0x00007ffff78e8da3 in
>>>> select () at ../sysdeps/unix/syscall-template.S:81
>>>> ---------------------------------------------------------------------------------------
>>> I'd have a blind guess:
>>> Thread 16 might be the "surviving" part of a python-spawned Timer()
>>> thread, which caused a message _post at another thread, which might be
>>> something that hangs if that block's thread no longer exists.
>>>
>>> Can you switch to that thread:
>>> thread 16
>>> and then try to get a python backtrace [1]
>>> py-bt
>>> and maybe a simple C-style backtrace
>>> bt
>>>
>>> that might give you some information what is actually waiting on a
>>> condition (which is what I guess from "pthread_cond_wait").
>>>
>>> Greetings,
>>> Marcus
>>>
>>> [1] for this to work, you might need to follow these instructions from
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:
>>>
>>> ... make sure that the python development package is installed
>>> (|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for
>>> some systems, you should append the content of
>>> |/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
>>> |~/.gdbinit|, and re-start |gdb|.
>>>
>> Marcus,
>>
>> Regarding the timer - this is what I thought at first, so I removed it
>> from the block. It didn't help, so I removed almost everything leaving
>> only message input of the block. But the problem persisted.
>>
>> I will try you advice with GDB and let everybody know of the result.
>>
>> Best Regards,
>> Piotr
>>
> Marcus,
>
> I did what you recommended but my knowledge of GDB doesn't let me
> interpret what I get to find the probably cause of the problem.
>
> Instead of sending output of GDB I'm sending simple python script so
> every interested person can see what doesn't work. Inside the script
> there is one message source and one message sink.
> The source sends one message to the sink. At the end the program should
> exit but it doesn't.
>
> Best Regards,
> Piotr Krysik
>
Hi all,

Reimplementing the block that uses message passing from Python to C++
did help.

The question remains - in more precisely formulated form:

***************************************************************************************
*Why "Run to completion" doesn't work with Python blocks that use
message passing?*
***************************************************************************************

For anyone who wants to debug this - I've attached Python code
demonstrating the problem to my previous message.

Best Regards,
Piotr Krysik



reply via email to

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