We have a problem with with a set of processes that uses mmap: the
file that is mapped by mmap gets corruped every now and then. I would
therefore like to hear if anybody on the list has had similar problems
and, maybe, found a work-around.
First let me specify the software and the versions we use:
- DEC OSF/1 V2.1 (Rev. 250)
- TeMIP Framework V200 (patch 6)
Note though that we don't know whether TeMIP is connected with this
problem at all.
We are in the business of making management modules for PolyCenter
TeMIP and have, in connection with a new access module, made a library
with a small effective in-core database.
The database is implemented by having a large file (40Mb or more)
mapped into the memory with mmap and then work on the file here. The
access to the file is protected with with a set of global locks. In
order to insure that we can survive a crash of the host alpha system
we let the database library use msync every time a modification has
been made.
The problem is that *sometimes* the mapped file gets corrupted with
areas with zeroes.
We have tried to:
- protect the database with mprotect around all authorized updates of
the database and we are reasonable sure that there are no wild writes
by other parts of the application.
- remove msync from all of the database code and just use a single
msync before munmap.
- make small test programs, that go through the same motions as
performed by the database, but using plain mmap, msync and
munmap. After some 20 different test scenarios we have yet to see
the error in this case.
Note that we have *not* been able to construct a small example that
can reproduce this problem, so have basically no ideas about what to
now...
The manual pages for the mmap facility contain some sections that
leave us a bit puzzled:
From msync:
After a successful call to the msync() function with the flags parameter
set to MS_SYNC, all previous modifications to the mapped region are visible
to processes using the read() parameter. Previous modifications to the
file using the write() function may be lost.
We suppose that this means that the mmap facility does *not* use the
UBC.
From mmap:
Modifications made to the file using the write() function are visible to
mapped regions, and modifications to a mapped region are visible with the
read() function.
This seems to be the opposite of the first: mmap uses the UBC.
But... whether the mmap facilities uses the UBC or not, we can not get
it to work!
-- tonny
Received on Tue Mar 07 1995 - 08:51:26 NZDT