Re: [Discuss-gnuradio] NetBSD and sysv shm

[Greg Troxel]

Eric Blossom <address@hidden> writes:

> On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg Troxel wrote:
>> I looked into this more, and conclude that there is no evidence for
>> bugs in NetBSD shm support, just perhaps resource defaults that aren't
>> big enough.
>> 
>> The reason so many attachments are needed is that 64 objects are
>> created, and each has 4 shmat calls.  This seems excessive, but I
>> don't know if the test is intended to consume that many resources.
>
> 64 is possibly a little high, but the idea was to have the failure at
> make check time rather than downstream at runtime.  At runtime there
> is a buffer object allocated for each output of each block.

That makes sense; it indeed fails at make check time because 256
attachments is higher than the defaults, which are 128 segments total
and 128 attachments per process (if I follow correctly).

My impression of the culture of sysv shm use has been that there are
fairly few shm segments, and that NetBSD's resource limits are
reasonable.  If that's a wrong impression I can try to change them,
but my impression is still that GNU Radio is a particularly heavy
user (which is fine, but not necessarily a reason to change the
defaults).  sysv shm is particularly troublesome because buggy code
can leak segments.

> There are 4 attaches to create each buffer.  Two of them are for guard
> regions on either side of the buffer.  Those regions are setup
> READ_ONLY, and are to trap write accesses off the beginning or end of
> the bufer. If munmap is available, we could modify the code to
> create holes that had no access.  The other two are the mappings that
> implement the two continguous copies of the circular buffer.

This is the sysv_shm case and the mmap case works fine, so there's no
real problem.  I was just curious why this failed because I thought
NetBSD had working sysv shm support.  Evidently it does, with lower
limits than the test needs, or at least the test finds no problems.

Interestingly, the 'junk pointer in free' message that I saw earlier
no longer appears.

pgpq3unsfep0N.pgp
Description: PGP signature