Re: possible problem with memory allocation using calloc/mmap/munmap
- Date: Mon, 20 May 2019 22:26:40 +0000
- From: Ken Brown <kbrown@xxxxxxxxxxx>
- Subject: Re: possible problem with memory allocation using calloc/mmap/munmap
On 5/3/2019 7:33 AM, Stanislav Kascak wrote:
> I came across a problem with memory allocation/deallocation when
> trying to compile and run tests of openldap under cygwin.
Corinna can give you a definitive response when she returns from vacation, but I
looked at the code and have a few comments.
> I created a test program to simulate sequence of actions. First a
> bigger chunk of memory (>~262kB) is allocated using calloc(), then
> mmap() is called with requested memory size much bigger than actual
> file size. Subsequently, munmap() to free previous mmap(), and at the
> end an attempt to access memory allocated with calloc(). That last
> memory access is causing Segmentation fault.
> It seems that when mmap() is called with length argument exceeding
> size of file, only memory to fit that file is allocated.
That's correct. The following comment in mmap.cc:1100 explains why: "don't map
beyond EOF, since Windows would change the file to the new length, in contrast
> however frees the full specified length. Since (at least on my
> computer) big chunk of memory allocated by calloc() is located after
> mmap() allocation, munmap() frees even memory of that calloc().
I think munmap does exactly what it's supposed to do according to Posix, which
is "remove any mappings for those entire pages containing any part of the
address space of the process starting at addr and continuing for len bytes." In
your case, that includes the memory allocated by calloc, which uses mmap.
I'm not sure what openldap is doing in your actual use case, but is there really
a good reason to call mmap with requested size much bigger than the actual file
size? After all, you can never access that extra memory. Posix says,
"References within the address range starting at pa and continuing for len bytes
to whole pages following the end of an object shall result in delivery of a
But let's wait and see what Corinna says.