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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
