By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,369 Members | 966 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,369 IT Pros & Developers. It's quick & easy.

std::bad_alloc - HP-UX

P: n/a
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:
Expand|Select|Wrap|Line Numbers
  1. #include <stdio.h>
  2. #include <unistd.h>
  3. #include <malloc.h>
  4.  
  5. int main(int argc, char* argv[] )
  6. {
  7.         int tam=744488960
  8.         char * c = new char[tam];
  9.         for (int i=0; i<tam-1; i++)
  10.                 c[i]= 32;
  11.         return 0;
  12. }
  13.  
Do you have any idea on how to solve it?
Thanks in advance.
Sep 28 '10 #1
Share this Question
Share on Google+
4 Replies


weaknessforcats
Expert Mod 5K+
P: 9,197
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.
Sep 28 '10 #2

Oralloy
Expert 100+
P: 983
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!
Sep 28 '10 #3

P: n/a
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.
Sep 29 '10 #4

Oralloy
Expert 100+
P: 983
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!
Sep 29 '10 #5

Post your reply

Sign in to post your reply or Sign up for a free account.