Bugs item #678250, was opened at 2003-01-31 11:44 Message generated for change (Comment added) made by mdr0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470

Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_mmap failling on AIX

Initial Comment: test_mmap is failing on a flush while trying to do: Copy-on-write memory map data not written correctly

The problem is that the mmap is opened with ACCESS_COPY. This translates to MAP_PRIVATE. On AIX, the msync man page says: "When the MS_SYNC and MAP_PRIVATE flags both are used, the msync subroutine returns an errno value of EINVAL."

I'm not sure what the correct fix should be.

----------------------------------------------------------------------

Comment By: Mark D. Roth (mdr0) Date: 2004-03-10 11:14

Message: Logged In: YES user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1. Is this something that's going to affect python if I put it into production, or is it "safe" to ignore it?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-07 16:06

Message: Logged In: YES user_id=33168

run the test with the -v flag: ./python ./Lib/test/regrtest.py -v test_mmap

I think only everything should be fine up to copy-on-write tests. Here's what a good run looks like:

[neal@epoch c3]$ ./python ./Lib/test/regrtest.py -v test_mmap test_mmap <type 'mmap.mmap'> Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\x00' Contents of first 3 bytes: '\x00\x00\x00'

Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\x00\x00' Contents of second page: '\x00foobar\x00' Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Creating 10 byte test data file. Opening mmap with access=ACCESS_READ Ensuring that readonly mmap can't be slice assigned. Ensuring that readonly mmap can't be item assigned. Ensuring that readonly mmap can't be write() to. Ensuring that readonly mmap can't be write_byte() to. Ensuring that readonly mmap can't be resized. Opening mmap with size too big Opening mmap with access=ACCESS_WRITE Modifying write-through memory map. Opening mmap with access=ACCESS_COPY Modifying copy-on-write memory map. Ensuring copy-on-write maps cannot be resized. Ensuring invalid access parameter raises exception. Test passed 1 test OK.

----------------------------------------------------------------------

Comment By: Richard Wheeler (wheelrl) Date: 2004-01-07 15:57

Message: Logged In: YES user_id=249546

I am getting the same error on AIX 5.2 with Python 2.3.3 release. What can I do to get around the test error and verify the mmap is working?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one) Date: 2003-05-06 15:00

Message: Logged In: YES user_id=31435

Hmm. I suspect the flush docs() are too strong (does flush really promise to materialize bytes *on disk*? it doesn't for other Python file objects, you also need os.fsync() for that).

Your point is well taken, though, and whatever flush() does normally do, it's not going to do it for a copy-on-write mmap. So fine by me if we declare that attempting to flush() a copy- on-write mmap raises an exception.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis) Date: 2003-05-03 05:09

Message: Logged In: YES user_id=21627

The documentation for flush says

"Flushes changes made to the in-memory copy of a file back to disk."

But it doesn't do that, and we all agree it shouldn't do that. So I would claim that it is an error to use .flush on an mmap object that was opened in ACCESS_COPY.

This is like trying to write to a file that was opened for reading only: one *could* declare that the write just does nothing, but it helps the developer more if you get an exception, because the code is likely wrong (i.e. not following the likely intentions of the author).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one) Date: 2003-04-28 14:55

Message: Logged In: YES user_id=31435

Sorry, I've had nothing to do with mmap beyond fixing bugs. The "access" feature was due to Jay Miller, although I believe I checked in his patch.

Martin, I don't understand why you think it's reasonable for flush to complain here: the mmap is open for writing, so what's surprising about expecting to be able to flush after a write? Simply that there's no associated file, due to copy-on- write? Then user code would have to be acutely aware of how an mmap'ed object was opened, just to avoid nuisance complaints when they flush after writing.

So that's a third alternative: alter the implementation to make mmap.flush() do nothing when an mmap object was opened as copy-on-write.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis) Date: 2003-03-04 01:00

Message: Logged In: YES user_id=21627

I think the test is somewhat bogus: It tries to check that modification to an ACCESS_COPY doesn't modify the underlying file, but assumes that .flush becomes a no-op, even though an exception is more reasonable (IMO; errors should never pass silently).

So I see two options: Declare that .flush() always raises an exception (and modify implementations that don't produce an exception accordingly), or declare that aspect to be system-dependent, and modify the test (and the documentation) to expect and ignore an exception.

Assigning to Tim, as he incorporated that feature into mmap.

----------------------------------------------------------------------