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