#5168: checking for working mmap... no --------------------------------+------------------------------------------- Reporter: andrewbachmann | Owner: axeld Type: bug | Status: reopened Priority: normal | Milestone: R1 Component: System/libroot.so | Version: R1/alpha1 Resolution: | Keywords: mmap malloc Blockedby: | Platform: x86 Blocking: | --------------------------------+------------------------------------------- Changes (by bonefish): * status: closed => reopened * resolution: invalid => Comment: I would say r34336 only causes the malloc() in the test program not to call resize_area() anymore, since the initial heap size has been increased and the incorrect check leading to unnecessary resize_area() calls has been fixed as well. I believe the next malloc() after exhausting all space of the initially allocated heap area will still fail. mmap()ing something into an existing area (like the heap area) works by splitting the original area into two pieces -- one before the mmap()ed range, and one after it. Since areas need to be contiguous, the latter is actually a new area (with a different ID). The heap implementation is not aware of this. It uses only a single area, which it resizes whenever it needs more memory. After splitting the area with mmap() this isn't possible anymore. After a failed resize_area(), the implementation could just try to allocate a new one to work with. That would be a good strategy also for the case that the heap area already adjoins another area. Or even more robustly, before resizing first get an area info for the heap area and always allocate a new one when there's a mismatch with the expected area base or size (an mmap() at the start of the heap area would move the base). If anyone wants to fix this, the function hoardSbrk() in src/system/libroot/posix/malloc/arch-specific.cpp is the one of interest. Otherwise I'll probably take care of it in the next days. -- Ticket URL: <http://dev.haiku-os.org/ticket/5168#comment:13> Haiku <http://dev.haiku-os.org> Haiku - the operating system.