Bug #525
Segfault running gnuradio flowgraph
| Status: | Closed | Start date: | 06/17/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Thomas Tsou | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
I modified a the spectrum_sense.py gnuradio script to use UHD. When I
tested it out on my N210, it worked fine. On my E100, I get a seg
fault.
This is the stack trace I got using gdb:
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 559]
0x400cc15c in sem_post () from /lib/libpthread.so.0
(gdb) thread apply all bt
Thread 2 (LWP 559):
#0 0x400cc15c in sem_post () from /lib/libpthread.so.0
#1 0x403246d0 in PyThread_release_lock () from /usr/lib/libpython2.6.so.1.0
#2 0x411af690 in gr_py_feval_dd::calleval(double) ()
from /usr/local/lib/python2.6/site-packages/gnuradio/gr/_gnuradio_core_general.so
#3 0x4066f084 in gr_bin_statistics_f::enter_tune_delay() ()
from /usr/local/lib/libgnuradio-core-3.4.0git.so.0
#4 0x4066f084 in gr_bin_statistics_f::enter_tune_delay() ()
from /usr/local/lib/libgnuradio-core-3.4.0git.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (LWP 549):
#0 0x4030b108 in PyArg_ParseTupleAndKeywords () from
/usr/lib/libpython2.6.so.1.0
#1 0x402792c8 in ?? () from /usr/lib/libpython2.6.so.1.0
#2 0x402792c8 in ?? () from /usr/lib/libpython2.6.so.1.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Any idea why this is happening?
History
#1 Updated by Philip Balister 11 months ago
More info:
On my E100 I'm running the console-e1xx-devel-image-usrp-e1xx.tar.gz
image from http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/Experimental_Images.
I built gnuradio and uhd from source, and did a git pull on uhd
yesterday.
The script I'm running is here:
https://github.com/mogar/uhd_utils/blob/master/uhd_spectrum_sense_sum.py
I'm running it with the command: python uhd_spectrum_sense_sum.py
--samp_rate=2000000 --num-tests=1 645M 651M
#2 Updated by Philip Balister 11 months ago
- Assignee changed from Philip Balister to Thomas Tsou
#3 Updated by Thomas Tsou 11 months ago
- Status changed from Assigned to Resolved
This is a GNU Radio issue rather then a problem with E100 or UHD. A quick solution was sent to the mailing list, though a more thorough fix involves replacing the current kludge with a way to inject Python back into gnuradio-core. A deeper solution is beyond the scope of UHD development.
This is a python-swig threading issue that occurs where the python
callback is passed into a c++ call. Basically, for whatever reason on
the E100, the python GIL (global interpreter lock) is never initiated.
There's a race on the release and the wrapper kludge gets confused.
Calling swig with the "-threads" option, a copious approach to
locking, is a quick, though blunt, solution.
diff --git a/Makefile.swig b/Makefile.swig
index 2ed69c6..fdac861 100644
--- a/Makefile.swig
+++ b/Makefile.swig
@@ -161,7 +161,7 @@ gnuradio/%.scm : %.i
@test -d "python" || $(mkinstalldirs) "python"
$(SWIG) $(STD_SWIG_PYTHON_ARGS) $($*_swig_args) \
-MD -MF python/$*.Std \
- -module $* -o python/$*.cc -oh python/$*.h $<
+ -threads -module $* -o python/$*.cc -oh python/$*.h $<
$(SED) -e 's|python/\(.*\)\.cc:|\1.py:|' python/$*.Std > python/$*.d
$(RM) python/$*.Std
--
In this case, the code in question, gr_feval.i, appears to exist
because of swig 1.3.xx limitations back in 2006.
#4 Updated by Thomas Tsou 11 months ago
- Issue stands beyond the scope of UHD.
- Swig branch created as wip. Cheap test case fix/hack presented that illustrates issue.
I setup a swig branch that makes gnuradio work with the '-threads'
option by removing conflicting manually inserted thread macros.
It remains a work-in-progress side project.
http://github.com/ttsou/gnuradio/commit/505e4e2ff28c01ce4534433bc57c69cf4b76724c
Alternatively, here's an interesting fix (hack) that works by firing
off a dummy thread to initialize the dependent lock variable. This
should work without any modifications to gnuradio.
diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py
index 70f530f..31bf458 100644
--- a/uhd_spectrum_sense_sum.py
+++ b/uhd_spectrum_sense_sum.py
@@ -32,7 +32,11 @@ import sys
import math
import struct
import time
+import threading
+class ThreadClass(threading.Thread):
+ def run(self):
+ return
class tune(gr.feval_dd):
"""
@@ -306,6 +310,9 @@ def main_loop(tb):
if __name__ == '__main__':
+ t = ThreadClass()
+ t.start()
+
tb = my_top_block()
try:
tb.start() # start executing flow graph in another thread...
--
#5 Updated by Thomas Tsou 10 months ago
Additional insight has materialized along with an easier solution, The
normal path that gnuradio takes to initialize Python threading, among
other methods, is through the ctypes library, which is not installed
by default on the E100 images.
I'm not sure why the absence of the module doesn't generate an error,
but the failure to load does show up in gdb.
strrchr (s=0xbef8ae08 "readline", c=46) at strrchr.c:29
29 strrchr.c: No such file or directory.
in strrchr.c
(gdb) bt
#0 strrchr (s=0xbef8ae08 "readline", c=46) at strrchr.c:29
#1 0x401f6ed0 in _PyImport_LoadDynamicModule ()
from /usr/lib/libpython2.6.so.1.0
#2 0x401f5100 in ?? () from /usr/lib/libpython2.6.so.1.0
python-ctypes being added to image updates.
#6 Updated by Matt Ettus 10 months ago
- Status changed from Resolved to Closed