Re: [Discuss-gnuradio] Python Script Stalls

[Johannes Demel]

-----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
> <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
>>> 
>> 
>> 
> 
> 
> 
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden 
> 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-----