Hi, > On Sat, 2009-07-18 at 12:28 -0700, Garrett Cooper wrote: > >> On Thu, Jul 16, 2009 at 11:37 PM, hefan<[email protected]> wrote: >> >>> hi, >>> >>> *[Patch 1/1] Patch for fixing the failed testcase openposix_mmap_11_4 >>> >>> -modified the file >>> *testcases/open_posix_testsuite/conformance/interfaces/mmap/11-4.c >>> First of all - this is really small explanation why you are fixing this issue. After some month none will know why you did this change.
>>> >>> Signed-off-by: fredrick he <[email protected]> >>> >>> --- >>> ltp.orig/testcases/open_posix_testsuite/conformance/interfaces/mmap/11-4.c >>> 2009-07-17 11:53:36.000000000 +0800 >>> +++ >>> ltp/testcases/open_posix_testsuite/conformance/interfaces/mmap/11-4.c >>> 2009-07-17 11:57:09.000000000 +0800 >>> @@ -130,7 +130,9 @@ int main() >>> flag = MAP_SHARED; >>> off = 0; >>> pa = mmap(addr, len, prot, flag, fd_2, off); >>> - pa_2 = mmap(addr, len, prot, flag, fd_2, off); >>> + addr = pa; >>> + memset(addr,0,len*2); >>> + pa_2 = mmap(addr, len, prot, flag|MAP_FIXED, fd_2, off); >>> if (pa_2 == MAP_FAILED) >>> { >>> printf("Test FAIL: " TNAME " Error at 2nd mmap(): %s\n", >>> >> Hi Fan, >> Some questions / observations: >> >> 1. Yes, the testcases does fail on my machine today. >> 2. Yes, doing what you say above does work (at least the testcase passes). >> 3. Are you positive that your set of steps above in fact don't >> invalidate the purpose of the testcase, by accident, in particular the >> memset call? I ask because of the following statement in the mmap >> manpage: >> >> If addr is NULL, then the kernel chooses the address at which to >> create >> the mapping; this is the most portable method of creating a new >> map- >> ping. If addr is not NULL, then the kernel takes it as a hint >> about >> where to place the mapping; on Linux, the mapping will be created at >> a >> nearby page boundary. The address of the new mapping is returned >> as >> the result of the call. >> >> What you're in effect doing is changing the 2nd mmap call from an >> arbitrary address to a set virtual address at 0x0. Is that indeed >> correct? >> > in this case, the situation is like this, we create a new file about 512 > bytes and mmap it into the mem, then we modify one byte besides the 512 > bytes address, and munmap it. and in the father process remmap it back > to check whether the one more byte is write back to the files. > > i have checked that when finished munmap and close the file in the child > process, the file didn't contain the 513th byte, the size of this file > is right 512 bytes.but in this case after the second mmap finished, the > 513th byte does appear again. it's a conflict. > > in my opinion this is because of the compiler or some optimizations. so > i think the memory should to be memset before mmap and it does work. > If is the problem with compiler/optimization means that tests is ok - the problem is with your compiler not with code. This need more investigations to find out where the problem is. Michal > >> 4. Have you talked to the openposix test suite folks about this yet? >> > no,i have no idea on how to talk to the openposix and i do want to talk > to them :) can you give me some suggestions about this? thx~ > > >> 5. FWIW the same results are seen on FreeBSD, so I don't doubt that >> the testcase is broken -- I just want to ensure that it's fixed in the >> proper way :)... >> > as mentioned above > > >> [gcoo...@optimus /scratch/open_posix_testsuite]$ >> conformance/interfaces/mmap/11-4.test >> pa: 0x800537000 >> pa_2: 0x800537000 >> Test Fail: mmap/11-4.c Modification of the partial page at the end of >> an object is written out >> [gcoo...@optimus /scratch/open_posix_testsuite]$ uname -a >> FreeBSD optimus.zenmetsuhitotuyaneshita.net 8.0-CURRENT FreeBSD >> 8.0-CURRENT #0: Sun Jul 5 14:43:07 PDT 2009 >> [email protected]:/usr/obj/usr/src/sys/OPTIMUS >> amd64 >> >> Thanks, >> -Garrett >> > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list > -- Michal Simek, Ing. (M.Eng) PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663 ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
