-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This happens when too many shared buffers are allocated but not released. It's an indicator that your flowgraphs are not terminated correctly. So I suppose the issue is to figure out what 'Ctrl-Z' really does.
On 12.11.2015 20:03, 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]> 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWRa5EAAoJEO7fmkDsqywMd2kP/jNXFDrnSgFd9TwEnGZw2925 G3BIhb5VrFJnSv+e/lGMggxREVC1V2CcG9AauIOtdT/sy2WNx/wZYSHwePbpsTCb C7kemB6CPX8tliDVWUDkoyL0ID+GVnDwpeq7pwduR+IjFrtRfWgEx6qTSumUec1J bL/nLL8HvVgha6XZMT2iJJd0AGSApTHZkRT1RLbOrvKjJaN4YoV4SxNqz8f2hyUo X74hnfAiz+fH4j7wkasz4rdoHkuBGsfkfzD13NGyP8zesr+57nxAlIdWZpsGPewo Q29gFlcU+QEjzqMrKDOvfLirqabpy0E67/LVdHbO6v0ksxHSWmCNPkH/WgPg6Pnu Fo+486Y+KhamuBXOU6oXlTzQ54O7qyBVOUmQMZDSJRqaNA4gsozlfj71yyqM7yVK 2EHqtpEwUe1UtgHHI17tlQDXB0EBbkLyRWbgElB2H0CNko0CYiomfiKVptUxJzss TgaypNrXI6QS40nUtwqoQ00G9HHMidZRJSP2bORt0cLLATNFHpDbBodGi+9wALqd bZM9dI33bfBwXl6+dGE5C3XaKRNK7T8srNwBwLjRM5p+o9ym0VZ3VhTPpBv5ywBh q3eU5sr2nJcdo3dChRS0mIwWxQwgxCuhFrHXi2gn2nyDMzZrNzotGz9gzS+sW+4R NQlcYJPKp4p1Nv/RX4AV =9VAF -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
