Regression: jemalloc >= 4.0 use munmap() even when configured with --disable-munmap

[Jason Evans]

On Apr 22, 2016, at 4:38 PM, Daniel Mewes <daniel at rethinkdb.com> wrote:
> In jemalloc 3.0, this patch added the `--disable-munmap` option and disabled the use of `munmap` on Linux by default: https://github.com/jemalloc/jemalloc/commit/59ae2766af88bad07ac721c4ee427b171e897bcb
> 
> It looks like jemalloc starting with version 4.0 makes use of `munmap` even when `--disable-munmap` is specified. From what I can tell, `chunk_map.c` honors the `config_munmap` flag, but the function `page_unmap` in `pages.c` ignores it (this code appears to be new in jemalloc 4?).
> 
> We are using jemalloc for RethinkDB and would like to upgrade to version 4.1 because we think that it fixes some bugs that our users have run into.
> However it causes a regression for https://github.com/rethinkdb/rethinkdb/issues/3516 :
> "<jemalloc>: Error in munmap(): Cannot allocate memory"

pages_unmap() is used to trim mappings so that what remains is chunk-aligned, regardless of whether --disable-munmap is specified.  jemalloc 3.x has similar code that calls munmap().  I don't see anything in what you're describing that is particular to jemalloc 4.x.  Are you able to determine anything else about the failure?  Its' extremely unusual for munmap() to fail (I've not seen it happen since ~2005 during initial development), so I'm guessing there's a memory corruption issue of some sort, whether due to a bug in jemalloc or RethinkDB.

Thanks,
Jason