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 <[email protected]> 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 < > [email protected]> wrote: > >> On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell <[email protected]> >> 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 >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
