std::bad_alloc - HP-UX

[Kaio Vieira]

Hello,

I have a "std::bad_alloc " problem when I try to run a simple C++ program on HP-UX. I don't know if it is a memory limitation or maybe a compiler option that I should use. When my program reaches 700M, it aborts.

I'm using gcc to compile.

This is the source:

#include <stdio.h>
#include <unistd.h>
#include <malloc.h>

int main(int argc, char* argv[] )
{
        int tam=744488960
        char * c = new char[tam];
        for (int i=0; i<tam-1; i++)
                c[i]= 32;
        return 0;
}

Do you have any idea on how to solve it?
Thanks in advance.

[weaknessforcats]

The code runs to completion on my Dell laptop machine.

My guess it's a limit of HP-UX. You might check woth your sysadmin to see if you are allowed that much heap.

[Oralloy]

Kaio,

HP-UX has a maximum amount of virtual memory that it actually can allocate in addition to any arbitrary limits put on your process.

Back, 15 years ago, I had a program, which illustrated a dynamic memory allocation error in the HP-UX FORTRAN compiler. It would run, continuously consuming heap until my image size was between 78 and 80 Mbytes.

People tried using the ulimit shell command to give the process infinite memory, but to no avail.

What was happening is that the ulimit was working, but I was exhausting nearly all of system memory before my image was aborted.

The total system memory size at the time is/was limited by available physical memory and swap partition space. It's just that back then our computers were slow and stupid. The jitter was caused by the difference in memory allocated to other processes running on the system.

So - ask yourself why you need so much memory, and work accordingly.

Cheers!

[Kaio Vieira]

Oralloy,

Thanks for your answer. I'd created this simple program just to prove that it is a memory limitation. My real application is much more complex than it.

But, when I compile this simple code as a 64-bit program (the machine is ia64), there is no problem during its execution.

So, this is really a HP-UX and 32-bit program limitation because the same code runs normally on a Linux (32-bit) server.

I'm still trying to find any solution. I can't recompile my application and I need to use more than 700M, as well as all Oracle processes that are running on the same machine.

[Oralloy]

Kaio,

I understand your frustration. When I was using HP-UX, we just didn't have gigabytes of memory available, so I never ran into the inherent operating system memory allocation limits.

You might want to look at how the O/S allocates memory addresses to find your absolute limits. From what I can see, it looks like the O/S has stripped two bits off the 32 bit address space, and you're sharing what's left with something. But - I may be very wrong, too.

Good Luck!