[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