discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Re-Occurrence of bug #199 in code based on gr_bin_sta


From: Thomas Arcuri
Subject: [Discuss-gnuradio] Re-Occurrence of bug #199 in code based on gr_bin_statistics_f
Date: Tue, 8 Feb 2011 09:06:27 -0500

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.

Finally, here is the system I tested on:
Fedora 14 64-bit
Linux tjadesktop 2.6.35.10-72.fc14.x86_64 #1 SMP Mon Dec 20 21:14:22 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
Intel i5 760
USRP 1 w/ WBX d'board

I have attached a small patch file which includes my fix. I could submit a formal fix if that would help, but I would really just like to get some feedback on the issue. What do you guys think?

Thanks!
-Tom


Attachment: gr_feval.i.patch
Description: Text Data


reply via email to

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