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): Taroon How reproducible: Always 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 (1MB). 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 Additional info: 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: DESCRIPTION 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 be mapped. 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. Thanks, Geoff Babb
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...