[prev in list] [next in list] [prev in thread] [next in thread]
List: haiku-bugs
Subject: [haiku-bugs] Re: [Haiku] #5168: checking for working mmap... no
From: "bonefish" <trac () haiku-os ! org>
Date: 2009-12-27 22:38:14
Message-ID: 058.95ca37178a78453cd726fab76581396f () haiku-os ! org
[Download RAW message or body]
#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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic