Red Hat Bugzilla – Bug 108500
Virtual address space allocation in EWS 3.0 differs from RH 8.
Last modified: 2007-11-30 17:06:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Description of problem:
Allocations of larger than 131060 bytes via malloc() are allocated very high in
memory, above 2GB (0xb7482008) in EWS 3.0. This behavior differs from RH8.0
and RH7.3, where allocations of this size were allocated just beyond
0x40000000. Our application does not handle addresses above 2GB well. Is
there any way to achieve the RH8.0 and RH7.x behavior on EWS 3.0?
I am attaching the source code.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Compile and build the source code with gcc 3.2 or higher.
2. ./rlimit 131061
3.Observe the addresses output.
4. Try same executable on RH8.x and compare results.
Actual Results: On RH8.0 the returned addresses are in the 0x40000000 range
On EWS3.0 the returned addresses are in the 0xb7000000 range (2-3MB).
Expected Results: I'd like the RH8.0 behavior on EWS3.0
If there is a configuration setting or workaround that will achieve the desired
behavior, I'd settle for that.
Created attachment 95598 [details]
Source code for a test case that demonstrates the problem.
Compile and run on EWS3.0 and RH8.0 and compare the results.
The problem is that you are using a signed int for the return value of
malloc(3), while malloc(3) does not return a variable of that type.
Instead, malloc(3) returns a pointer. Lets take a look at the malloc(3) man page:
calloc() allocates memory for an array of nmemb elements
of size bytes each and returns a pointer to the allocated
memory. The memory is set to zero.
malloc() allocates size bytes and returns a pointer to the
allocated memory. The memory is not cleared.
A pointer is either 32 or 64 bits, depending on the architecture. On 64 bit
systems your returnval variable would be only half the needed size!
You really want to declare returnval a char* or similar, so it can store a whole
pointer. Let me know if you need more information.
Note that setting the address space limit to 2GB means you can use up to 2GB out
of the 3GB of address space, it does NOT mandate where the parts of memory can
In RHL7.x, RHL8, RHL9 and WS3 the stack of the process will grow down from 3GB,
ie. above the 2GB limit. Try printing the address of a stack local variable ...
I'm going to reopen this bug because you didn't really address the problem I'm
trying to solve. The way that I declare the value returned from malloc() is
irrelevant to the issue I'm trying to pursue, which is why large allocations
(>128K) malloc()'s on RH 8.0 are allocated in the 1GB (0x400000) range, while
large malloc()'s on EWS3.0 allocate memory in the 2-3GB (0xb00000) address
range. Is this within the implementation of malloc()? We are using the malloc
() that comes with gcc 3.2. If this is the case, how does malloc allocate
memory that high in the address space? It is doing something other than the
classic sbrk(). It also seems to have 2 allocators, one for small blocks
(<128K) and one for large blocks (>128K). Perhaps this isn't a kernel issue,
but it seems to be interrelated to the kernel.
It's not a kernel issue. Yes the kernel now has a slightly different way of
handing out memory, but it perfectly entitled to do so. Your application needs
to be fixed. Really. ia32 is a 32 bit not a 31 bit architecture...