On Fri, Aug 02, 2002 at 02:29:25PM -0700, Wichmann, Mats D wrote: > LSB-si/ia32: with Anthony Towns' fix to mprotect, > the hang is gone. > Total failures: 1 > > T.msync 7 claims that the sequence: mmap 1 page, > msync 2 pages at address returned by mmap does not > fail when it should. LSB.os/mfiles/msync_P/T.msync_P in full, presumably > This is one that behaves > as the test expects on the same system running > natively, and could be either a library change > (which I can't spot) or another test-interaction > problem like the mprotect test was (I can't spot > that, either). I get the same thing, running natively on a minimal Debian system. It doesn't seem to be a test interaction problem: just run ./T.msync_P 7 alone fails in the same way. At a guess, it's probably that libc's mapping something in the area just after our mmap, and we're accidently msync'ing that as well as our stuff. Perhaps a better test strategy would be to do something like: char *x = malloc(vsrt_pgsz); char *y = mmap(...); char *addr = min(x,y); size_t size = max(x,y) - start + vsrt_pgsz; msync(addr, size, MS_SYNC); thus ensuring that _some_ of the memory isn't mmap'ed? (Or is malloc allowed to return memory mmap'ed against /dev/null or similar?) Alternatively, you could do two mmap's, then munmap one of them, and go from there, but that memory could've been reused by libc as part of the munmap, conceivably. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgpfHd1SCafR8.pgp
Description: PGP signature