From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: OPTS tests: mmap/11-4.c mmap/11-5.c These testcases check if a modification after the end of a mmap'ed area is written out (POSIX requires it shall not be). Details are available at: http://nptl.bullopensource.org/Tests/results/report.php Browse: (TC2) 2xi686HT - RHAS4u2 Run 1,2,3 See: http://nptl.bullopensource.org/Tests/results/detailed.php?run_id=10&testcase_id=3430 Version-Release number of selected component (if applicable): Unmodified RHEL4u2 How reproducible: Always Steps to Reproduce: Use OPTS. (Used version was: OPTS cvs repository on Nov 14, 2005) Actual Results: See: http://nptl.bullopensource.org/Tests/results/detailed.php?run_id=10&testcase_id=3430 Additional info:
Why are you filling this (and several other bugreports) against glibc and what does it have to do with NPTL? If it is not testsuite bug (haven't investigated now; last time I looked at that testsuite most of the reported failures were because of testsuite bugs), then what you are describing doesn't have anything to do with NPTL, even not glibc, but kernel behaviour. mmap in glibc is a simple wrapper around kernel syscall and writing out the pages is also kernel task.
Use the 3 (correct !) URLS: http://nptl.bullopensource.org/Tests/TC2/report.php#problems http://nptl.bullopensource.org/Tests/results/run-browse.php Click the "Browse" button of : (TC2) 2xi686HT - RHAS4u2 Run 3 You can also select 2 runs and click the "Compare Selected" button.
Sorry, I've put "NPTL: " at the beginning of each bugzilla by mistake. Only the 3 last ones deal with glibc:NPTL. The 4 first ones deal with glibc:mmap. Since we have used the OPTS, which is aimed to test the POSIX beaviour, I don't care if the feature is implemented in glibc or in the kernel. Feel free to change the component as needed. About the OPTS testsuite bugs, we have spent time analyzing the errors provided by OPTS, and we really think these 7 bugs are not due to the testsuite.
hi Tony, Both test cases look incorrect to me. 11-4.c From the mmap man page: "For a file that is not a multiple of the page size, the remaining memory is zeroed when mapped, and writes to that region are not written out to the file." The manpage says nothing about writes to memory. That is, the byte written to len+1 is in memory, not on disk. The following patch corrects testcase 11-4.c --- ./conformance/interfaces/mmap/11-4.c.bak 2006-01-17 11:47:04.000000000 -0500 +++ ./conformance/interfaces/mmap/11-4.c 2006-01-17 11:47:30.000000000 -0500 @@ -112,6 +112,7 @@ /* Write the partial page */ *ch = 'b'; munmap (pa, len); + fsync(fd); close (fd); return PTS_PASS; } Regarding testcase 11-5.c, it is not a bug either for the same reason. Since the shared memory region has no real file behind we can not use the fsync trick.