Red Hat Bugzilla – Bug 176928
NPTL: Modification after the end of mmap'ed area
Last modified: 2007-11-30 17:07:22 EST
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:
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:
Browse: (TC2) 2xi686HT - RHAS4u2 Run 1,2,3
Version-Release number of selected component (if applicable):
Steps to Reproduce:
(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
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:
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.
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);
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.