On Apr 22, 2016, at 4:38 PM, Daniel Mewes <[email protected]> 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 _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
