memory cannot be extended in EXEC_MAGIC mode

[xbin999]

My 32-bit mode program needs to exceed 1G limit.
My test code just looks like this:
vector b;
b.reserve(100000000);
cout << b.size() << ":" << b.capacity() << endl;
vector c;
c.reserve(100000000);
cout << c.size() << ":" << c.capacity() << endl;
vector d;
d.reserve(100000000);
cout << d.size() << ":" << d.capacity() << endl;
Each vector instance's memory is nearly 390M.
I compiled the source with:
%aCC -Wl,-N testmem.cpp -o testmem
And chatr it:
%chatr testmem
testmem:
normal executable
But while I runned my test program, core dumped.
What's wrong?
Thanks a lot.

[Derek Whigham_1]

Run chatr and file against you executable and you should see something as below

then uses chatr +q3p enable to switch on the third quadrant +q4p enable for the forth.


chatr daw.run
daw.run:
shared executable
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
shared library list:
dynamic /usr/lib/librpcsoc.1
dynamic /usr/lib/libnsl.1
dynamic /usr/lib/libc.2
shared library binding:
deferred
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
explicit unloading enabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
third quadrant global data space disabled
data page size: D (default)
instruction page size: D (default)
nulptr references disabled
shared library private mapping disabled
shared library text merging disabled


file daw.run
daw.run: PA-RISC1.1 shared executable dynamically linked -not stripped

[xbin999]

I had solved the problem. It's my fault. I had no prividge to check the system parameter yesterday. Now I just asked admin show me the parameter: 'maxdsize' is only 1GB. And I had run the 'testmem' in another host. It's ok.

Thanks Derek.
"+q3p", "+q4p" can make the 3nd, 4th quadrant as private data space. I think it only can be used in SHMEM_MAGIC, and only 32-bit kernels supported. Is it right?

[Bill Hassell]

You should recode your program to check for the success of the memopry allocation, not crash. Far too many programmers overlook this critical test and leave sysadmins scrambling to determine the reason for a crash.

No, SHMEM_MAGIC refers to a separate dataspace where there are some simularities but you can grab 3600 megs of local data with a 32bit program. I have attached a simple program that runs on 10.20 and higher, which can be compiled in 5 different ways and obtain 900, 1700, 2700, 3600 megs for a 32bit program and essentially unlimited RAM when compiled in 64bit mode. The 32bit program runs on 32 and 64bit systems, but the ability of +q3p and +q4p tro function depends on patches and HP-UX rev. See the program code for comments.

[Alzhy]

I actually suggest if you have not used it yet a tool called dmalloc (www.dmalloc.com).