Bug 108500

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