Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 108500 - Virtual address space allocation in EWS 3.0 differs from RH 8.
Virtual address space allocation in EWS 3.0 differs from RH 8.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-10-29 20:32 EST by Geoff Babb
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-30 08:21:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Source code for a test case that demonstrates the problem. (1.33 KB, text/plain)
2003-10-29 20:34 EST, Geoff Babb
no flags Details

  None (edit)
Description Geoff Babb 2003-10-29 20:32:50 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):

How reproducible:

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

Additional info:

If there is a configuration setting or workaround that will achieve the desired 
behavior, I'd settle for that.
Comment 1 Geoff Babb 2003-10-29 20:34:55 EST
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.
Comment 2 Rik van Riel 2003-10-29 21:02:58 EST
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.
Comment 4 Rik van Riel 2003-10-29 21:11:06 EST
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 ...
Comment 5 Geoff Babb 2003-10-30 01:19:22 EST
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.


Geoff Babb
Comment 6 Arjan van de Ven 2003-10-30 08:21:01 EST
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...

Note You need to log in before you can comment on or make changes to this bug.