checking for working mmap... no

[andrewbachmann]

REVISIONS from R1/alpha1 through hrev34335 exhibit the following behavior:

While trying to configure a gcc build I noticed configure said:

"checking for working mmap... no"

I extracted the test program from the configure script and it fails in a malloc. I have added printfs to the program so as to make it more descriptive. The error printed is: "data3 null". The failing line is: data3 = (char *) malloc (pagesize);

To compile this program, simply: gcc mman.c -o mman And run ./mman

I am running revision 34251, gcc2hybrid. The program fails if I compile it with gcc2.95.3-haiku-090629 or if I compile it with gcc 4.4.2 (from joe protsko).

THE ABOVE BEHAVIOR WENT AWAY in hrev34336 from 11/29/09 09:20:58

[augiedoggie]

The sample code is working for me in hrev34761 with both compilers.

[andrewbachmann]

I compiled and ran it in 34655 and it worked fine. I took the same executable to 34251 and it failed. So, I guess this has been fixed in the meantime.

[andrewbachmann]

It seems like this was working in hrev34451 as well.

[andrewbachmann]

This test program is working in hrev34348 and that version also seems to support the BeZillaBrowser without the 'instaclose' problem in hrev34451 hrev34655 and hrev34761.

[andrewbachmann]

This test program is working in hrev34427 and that version also seems to support the BeZillaBroswer without the 'instaclose' problem.

[andrewbachmann]

My test results for BeZillaBrowser instaclose may not be valid since this install also seems to be working in hrev34760. Something else is at work here.

[andrewbachmann]

Revision 1 alpha 1 has this bug.

[andrewbachmann]

hrev34302 has this bug.

[andrewbachmann]

hrev34322 has this bug.

[andrewbachmann]

hrev34335 has this bug.

[andrewbachmann]

hrev34336 is the first working version. (does not exhibit the bug behavior)

[bonefish]

I would say hrev34336 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.

[bonefish]

Fixed in hrev34897.