Re: [Discuss-gnuradio] Python Script Stalls

[Richard Bell]

I thought I'd add this bit of information. After stopping a number of simulations by pressing 'Ctrl-Z' in the middle of the sim, I will get the following buffer error:

gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

I found a post that Martin Muller made explaining how to overcome this (execute: sudo sysctl kernel.shmmni=32000),  but I'm more interested in whether this could be related to the stalling I'm seeing.

Rich

On Thu, Nov 12, 2015 at 9:27 AM, Richard Bell <address@hidden> wrote:

Glad you cleared that up, but unfortunately this isn't the fix to my problem. The flowgraph for some iterations (seemingly random) still stalls so that I have to hit 'Ctrl-C' to get it to move on.

To be more clear on the "random" stall, here is what happens. I have 10 different simulation iterations I want to run on the base radio. The parameter I change is the injected noise standard deviation between each iteration. Sometimes, the script will make it through all 10 runs with no issue. If I run the script again, the 2nd and 8th iteration might stall. Now I run it again, and only the 4th stalls. I run it again and I get no stalls. I run it again and the 5th and 6th stall. It's behavior like this that I'm seeing.

In between each for loop iteration, I'm doing this in Python:

for n in xrange(0, 10):

    tb = top_block()

    tb.start()

    tb.wait()

    tb.stop()

    tb.wait()

    tb = None

I'm guessing at this point I'm on my own. If anyone knows of a good bit of info I should have when making these multi-run simulations in python, please let me know.

Apprecaited,

Rich

On Wed, Nov 11, 2015 at 1:35 PM, Johnathan Corgan <address@hidden> wrote:

On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell <address@hidden> wrote:

John, did you mean this four step process, otherwise stop before wait doesn't let anything happen:

tb.start()

tb.wait()

tb.stop()

tb.wait()

Like that? If so, why don't the auto-generated top_blocks have to do that?

​To clarify what is happening under the hood here, let me go through what these calls actually do.

tb.start() creates and runs a thread for each block in the flowgraph, and immediately returns to the foreground thread execution. One uses this form when one wants to continue to do other things in the application while the flowgraph is running in the background.  This is typically used with GUI applications that have their own event loop thread.

At the end of the application, one must call tb.stop(), which issues a cancel to each thread, and then tb.wait(), which joins each thread and ensures everything is cleaned up before continuing.

​Now, flowgraphs can either exit on their own, such when a finite data source is used, or a head() block is in place, or they run indefinitely.  In either case, if the flowgraph is started with tb.start(), it must eventually be followed with tb.stop() and tb.wait().

The alternative, which is more common in non-GUI scripts, is to use tb.run().  This will internally call start(), and then block either until the flowgraph to exits on its own, or a SIGINT (ctrl-c) arrives.  It then calls tb.stop() and tb.wait() internally, then returns.

Thus, the simpler tb.run() semantics let you create a flowgraph, let it run till exit, or break out of it with SIGINT.  When tb.run() returns, there is nothing else the user needs to do.  Hence, many command-line examples you see in GNU Radio use tb.run().  If they use the tb.start() method, which again, returns immediately to the foreground, they usually have a raw input call or something else that blocks until the user does something, then they call tb.stop() and tb.wait().

It sounds like what you are trying to do, if I understood correctly, is run a finite-length flowgraph over and over again.  For that, tb.run() should suffice.  If the flowgraph is not guaranteed to exit on its own, then you'll need to do tb.start(), block while you figure out whether conditions are proper for terminating the flowgraph, then do tb.stop() and tb.wait().

-- 

Johnathan Corgan
Corgan Labs - SDR Training and Development Services

http://corganlabs.com