Hello all,
It looks as though I have uncovered GNU Radio bug #199 in one of my
programs. I used gr_bin_statistics_f as a template and designed a new
block which uses the same method to callback to Python code and retune
the USRP.
http://gnuradio.org/redmine/issues/show/199
Now, I could get into more details of my specific program, however it
seems like this bug could be hard to replicate on different hardware. I
am not sure to the extent of the issue, but I know where the problem is.
---
The problem occurs in the callback code in gr_feval.i. As described in
the bug report, Py_GILState_Ensure() is called before calleval(), and
then Py_GILState_Release() is called after returning from Python land.
It is at this point that I get a segmentation fault.
For a gdb stacktrace similar to that on the bug report, please refer to
my blog post:
http://tomonprogramming.blogspot.com/2011/02/gnu-radio-bug-199.html
After googling around for a while I read about similar issues which were
solved by adding a call to PyEval_InitThreads() right before
Py_GILState_Ensure() is called (hinted at in the bug report). This did
the trick for me! Calling PyEval_InitThreads() acquires and initializes
the GIL, and calling it multiple times is a NOOP. More details can be
found in Python documentation. I am not sure if this is the correct
solution, but it worked for me. Others have suggested to me that the module using the multi-threaded Python extension should 'import threading' early to ensure that PyEval_InitThreads is called.