On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg T. 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
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.
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.
Eric and I have recently beat on the few known NetBSD nits; now make
check passes on NetBSD 4.0_BETA2 with up-to-date packages from pkgsrc
(including jack, port-audio, SDL, py-ephem so most components are
Greg T. <[email protected]>