An Interesting one, on my system wine has been broken for a little while failing with a bad heap message I have tracked it down to one solitary line in Virtual.c:(115) and here it is :
#define ADDRESS_SPACE_LIMIT ((void *)0xc0000000) /* top of the user address space */
when making an anonymous mmap Solaris returns (gdb) disp ptr 11: ptr = (void *) 0xdf620000 (ptr gets copied to base later)
Which is somewhat larger than 0xc0000000 and a comparison at around line 1010 if ((base <= (char *)granularity_mask) || (base + size < base) || (base + size > (char *)ADDRESS_SPACE_LIMIT)) { SetLastError( ERROR_INVALID_PARAMETER ); return NULL; }
Fails
Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux thing. My only way to work around it would be to "strongly Suggest* mapping addresses to the OS which would be very messy.
Suggestions (Constructive ones) warmly received
Bob
#define ADDRESS_SPACE_LIMIT ((void *)0xc0000000) /* top of the user address space */
when making an anonymous mmap Solaris returns 11: ptr = (void *) 0xdf620000
Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux thing.
It is actually a hardware feature, IIRC it is the address above which the cache ignores process contexts (cache colours). This means that kernel code/data is shared (in the cache) by all processes.
For the sparc reference mmu (used by all sun sparc systems for many many years) the address is 0xe0000000. As someone put it 'the kernel has to shoehorn itself into only 512Mb' [1].
I suspect you want to make ADDRESS_SPACE_LIMIT architecture dependant. For non-x86 you can (presumably) use OS assigned mmap addresses throughout - or is the used of known mmap addresses pervasive?
David
(This first became a problem as memory sizes approached 512Mb and it no longer became possible to have all of physically memory mapped into kernel address space).
On Mon, 19 Aug 2002 22:07, David Laight wrote:
#define ADDRESS_SPACE_LIMIT ((void *)0xc0000000) /* top of the user address space */
when making an anonymous mmap Solaris returns 11: ptr = (void *) 0xdf620000
Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux thing.
It is actually a hardware feature, IIRC it is the address above which the cache ignores process contexts (cache colours). This means that kernel code/data is shared (in the cache) by all processes.
For the sparc reference mmu (used by all sun sparc systems for many many years) the address is 0xe0000000. As someone put it 'the kernel has to shoehorn itself into only 512Mb' [1].
I suspect you want to make ADDRESS_SPACE_LIMIT architecture dependant. For non-x86 you can (presumably) use OS assigned mmap addresses throughout - or is the used of known mmap addresses pervasive?
David
(This first became a problem as memory sizes approached 512Mb and it no longer became possible to have all of physically memory mapped into kernel address space).
OK well judging by Solaris x86 behaviour E0000000 is used there also, and is allocated in reverse . I suggest then that I should set ADDRESS_SPACE_LIMIT to E0000000 for all Solaris targets.
Robert Lunnon bob@yarrabee.net.au writes:
Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux thing. My only way to work around it would be to "strongly Suggest* mapping addresses to the OS which would be very messy.
It's a Windows thing. Some brain-damaged apps cannot cope with an address space that goes beyond 0xc0000000. A possible work around would be to create an anonymous mmap covering the addresses above 0xc0000000 to make sure nothing gets allocated there later on.
On Tue, 20 Aug 2002 07:08, Alexandre Julliard wrote:
Robert Lunnon bob@yarrabee.net.au writes:
Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux thing. My only way to work around it would be to "strongly Suggest* mapping addresses to the OS which would be very messy.
It's a Windows thing. Some brain-damaged apps cannot cope with an address space that goes beyond 0xc0000000. A possible work around would be to create an anonymous mmap covering the addresses above 0xc0000000 to make sure nothing gets allocated there later on.
This would be an answer, I'll have a look at this approach.
-
Alexandre Julliard -
David Laight -
Robert Lunnon