[haiku-bugs] Re: [Haiku] #5168: checking for working mmap... no

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Sun, 27 Dec 2009 22:38:14 -0000

#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.

Other related posts: