No, this is (pretty certainly) unrelated. Buffer allocation happens before the flowgraph can even start.
Best regards, Marcus On 11/12/2015 08:03 PM, Richard Bell wrote: > 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] > <mailto:[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] <mailto:[email protected]>> wrote: > > On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell > <[email protected] <mailto:[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
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
