Opened 10 years ago

Closed 10 years ago

#5168 closed bug (fixed)

checking for working mmap... no

Reported by: andrewbachmann Owned by: axeld
Priority: normal Milestone: R1
Component: System/libroot.so Version: R1/alpha1
Keywords: mmap malloc Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description (last modified by 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

Attachments (1)

mman.c (4.2 KB ) - added by andrewbachmann 10 years ago.

Download all attachments as: .zip

Change History (15)

by andrewbachmann, 10 years ago

Attachment: mman.c added

comment:1 by augiedoggie, 10 years ago

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

comment:2 by andrewbachmann, 10 years ago

Resolution: invalid
Status: newclosed

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.

comment:3 by andrewbachmann, 10 years ago

It seems like this was working in hrev34451 as well.

comment:4 by andrewbachmann, 10 years ago

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.

comment:5 by andrewbachmann, 10 years ago

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

comment:6 by andrewbachmann, 10 years ago

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.

comment:7 by andrewbachmann, 10 years ago

Revision 1 alpha 1 has this bug.

comment:8 by andrewbachmann, 10 years ago

hrev34302 has this bug.

comment:9 by andrewbachmann, 10 years ago

hrev34322 has this bug.

comment:10 by andrewbachmann, 10 years ago

hrev34335 has this bug.

comment:11 by andrewbachmann, 10 years ago

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

comment:12 by andrewbachmann, 10 years ago

Description: modified (diff)

comment:13 by bonefish, 10 years ago

Resolution: invalid
Status: closedreopened

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.

comment:14 by bonefish, 10 years ago

Resolution: fixed
Status: reopenedclosed

Fixed in hrev34897.

Note: See TracTickets for help on using tickets.