Forum: GNU Radio ephemeral error in threading

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Cc199e88dbca031201c834e5a722514e?d=identicon&s=25 John Bratteli (Guest)
on 2007-06-18 22:50
(Received via mailing list)

We have been having a bit of a problem with GnuRadio
hanging when we call run() on a created flow graph and
wanted to see if anyone had any ideas or suggestions
for resolving the issue.

We have installed the latest version of the GnuRadio
libraries 3.0.3. However, we also saw the problem on
the previous version 3.0.2.  Our application creates
and runs many small flow graphs to capture a signal
sample from a physical usrp board for 0.001 of a
secondond.  The problem happens inconsistently.
Sometimes it will happen on the 4th or 5th flow graph
we create and run, sometimes it takes a very long
time, if ever, for the problem to occur.  Basically we
create a flow graph g, and call and it never

The creation of our particular flow graph looks
something like the following (I have only included the
essential code segments, so some references and code
are missing):


# Some code has been removed to simplify
    def __init__(self, options, freq=88.9e6,
        usrp_wrapper_decimation = 16
        adc_rate = 64e6 # constant for USRP
        nsamples = adc_rate /
float(usrp_wrapper_decimation) * duration
        self.src =
        self.dst = gr.vector_sink_s()
        self.head = gr.head(gr.sizeof_short,
        self.connect(self.src, self.head, self.dst)
        r = self.u.tune(0, self.subdev, freq)

def captureSample(self, freq, duration, subdev = None,
store = False):
    print "<UsrpWrapper.capturSample> Capturing sample
at freq:", freq, "dur:", duration
    options.usrp_wrapper_subdev = subdev
    g =
UsrpWrapperServerCaptureFlowGraph(self.options, freq,

    print "<UsrpWraper.capturSample> ... about to
capture sample by ..."
    print "<UsrpWraper.capturSample>  ... returned
from Done ... "



As I described above, the captureSample() function can
be called many times and it will successfully
communicate with the usrp board, capture a sample by
running the flow graph, and return the sample as a
vector of shorts.  However, eventually after calling
captureSample() many times, the function will be
entered and we will get the debug message before the
call to

<UsrpWrapper.capturSample> Capturing sample at freq:
360000000.0  dur:
Using RX d'board B: TV Rx Rev 3
USB sample rate 4M
<UsrpWraper.capturSample> ... about to capture sample
by calling ...

but will never return.


We have added some print/debug statements into the
gnuradio library code to get some further information.
 After examining things for a bit we have found the
following. The gnuradio code appears to be entering an
infinite loop in the wait() method for the scheduler
class in the gnuradio/gr/ file.  I have
made the following modifications to the wait() method
of the scheduler:

----------- our version of wait() function for
scheduler class
----------- in gnuradio/gr/

    def wait(self):
        print "<scheduler.wait> entered, before for
        for (sts, thread) in self.state:
            print "<scheduler.wait> in for loop sts=",
sts, "thread=", thread
            timeout = 0.100
            print "<scheduler.wait> after setting
timeout, before while True loop"
            numJoinAttempts = 0
            while True:
                print "<scheduler.wait> before
attempting thread join"
                print "<scheduler.wait> now check if
thread is alive or not, if not we break out"
                if not thread.isAlive():
                    print "<scheduler.wait> dead
thread, should break out of this loop, this was a
normal halting condition"


Basically if we run our code, and look at the messages
from the wait function as I have show above, we will

<flow_grapy.wait> before we call scheduler.wait()
<scheduler.wait> entered, before for loop
<scheduler.wait> in for loop sts=
readed_scheduler_sptr; proxy of <Swig Object of type
er_sptr *' at 0xa16d280> > thread=
<scheduler_thread(Thread-9, started
<scheduler.wait> after setting timeout, before while
True loop
<scheduler.wait> before attempting thread join
<scheduler.wait> now check if thread is alive or not,
if not we break out
<scheduler.wait> before attempting thread join
<scheduler.wait> now check if thread is alive or not,
if not we break out
<scheduler.wait> before attempting thread join
<scheduler.wait> now check if thread is alive or not,
if not we break out
<scheduler.wait> before attempting thread join
... infinite loop ....

Basically the thread.join() call never succeeds, and
we never break
out of the while loop.


So that is where we are at the moment.  I haven't been
able to determine if I have uncovered some legitimate
race condition or heisenbug with the gnuradio flow
graph threading and scheduling code,
or if we are doing something a bit silly in our
creation/usage of a gnuradio flow graph.  Any help,
suggestions or ideas would be greatly welcomed.  We
will try and pin down the problem more specifically if
we have to, but wanted to check with the community at
large first before getting deep into the
threading/scheduling guts and discovering either a)
someone has already fixed it or b) we are doing
something silly and/or stupid in our creation and use
of the flow graph.

Thanks in advance,
Derek Harter / John Bratteli
Texas A&M-Commerce

Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight
and hotel bargains.
This topic is locked and can not be replied to.