A simple C++ program crashing on HP machine.

[Don Raman]

I have a simple program:

int main()
{
char* abc = new char[750000000];
return 0;
}

When I comile it with aCC (no options used) and try to run I get the error:

~/a.out
IOT trap (core dumped)

This is the result of uname -a
HP-UX cs16 B.11.00 U 9000/785 2013098884 unlimited-user license

Running top shows this:

Load averages: 0.13, 0.13, 0.13
381 processes: 351 sleeping, 22 running, 8 stopped
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.19 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
1 0.08 0.0% 0.0% 0.8% 99.2% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 0.13 0.0% 0.0% 0.4% 99.6% 0.0% 0.0% 0.0% 0.0%

Memory: 1246620K (822040K) real, 1036104K (810408K) virtual, 4590660K free Page
# 1/35

On another HP machine, I am facing the same problem but at a higer memory allocation. Is there something which can be done to fix this?

[Don Raman]

Compiler version is:

/opt/aCC/bin/aCC --version
aCC: HP ANSI C++ B3910B A.03.31

[Don Raman]

The program runs fine when I compile it with

aCC: HP ANSI C++ B3910B A.03.52

Also if I use malloc instead of new it runs with older compiler too. But my problem is that I cannot use malloc as I am creating class object. Also I cannot use the latest compilers because that is a decision to be made by division and I cannot deviate. Any other alternative?

[A. Clay Stephenson]

Almost certainly your 750000000 exceeds maxdsiz (or maxdsiz_64bit if you compiled as a 64-bit executable). You need to either increase maxdsiz or reduce the size of the array to something below maxdsiz. You could also be running out of virtual memory (swapspace) but the maxdsiz limit is the much more likely culprit.

[Don Raman]

Mine is a 32 bit executable and maxdsize is set to a much higer limit (around 3 GB). Also the same program works using the latest aCC compiler or changing new to malloc. So I am certain this is a genuine defect in the new implementation which got addressed in the latest release. My only problem is that I cannot use the latest compiler.

Regards,
Don.

[A. Clay Stephenson]

If you must remain at this compiler version, you could try installing the run-time library patch(es). You might get some hists as to the problem by compiling with -g, letting it crash, and then use gdb to examine the stack trace.

[Don Raman]

I tried -g option. When I am wathing it with gdb it is telling me cannot access memory location at a certain point. the trace goes to new implementation.

I also tried installing the latest runtime executable but it's not working. It works only when I use the latest compiler or replace new with malloc.

Regards,
Don.

[A. Clay Stephenson]

If you must remain at that compiler version (which is state of the art stupid) then the only thing I can suggest is that you compile
with the -S -g options on the older compiler and then use a newer version of the compiler with the same options. You then could examine the .s (assembly source) and find the differences and maybe add a step to your makefile to patch the assembly source and then invoke the assembler. It's dumb but it just might allow you to outbushwhack the problem w/o upgrading the compiler.

[Ermin Borovac]

Just out of curiosity does your simple program work if you compile it with aCC's -N switch?

[Don Raman]

The sample program did work with -N option. -N option means that the program is not sharable. I don't know how it solves this problem. Any idea? By the way I will compile my original executable with this option and give you an update.

Regards,
Don.

[Don Raman]

By the way, I found one more workaround. When I use a combination of malloc with placement new it does work.

Please see the program below which works:

#include
#include
#include
using namespace std;
class B
{
int abc;
public:
virtual void seti( int aaa) {abc = aaa;}
};

class A : public B
{
int i;
public:
void seti(int a) { i=a; }
int geti() { return i; }
};

int main()
{
long i = 0;
for (i=0; i<=80000000; i++)
{
//A* ptr = new A();
void* space = malloc(sizeof(A));
A* ptr = new(space) A();
}
return 0;
}

The above program also worked fine without any option.

Regards,
Don.

[Ermin Borovac · Accepted solution]

32-bit process memory space is divided into 4 quadrants, each quadrant being 1G in size.

Malloced space goes into 2nd quadrant, so by default you can allocate maximum of 1G (even if maxdsiz is greater than 1G).

Process stack also goes into 2nd quadrant. Stack space is reserved with maxssiz, which means that large maxssiz will reduce amount that can be malloced. There are some other areas in 2nd quadrant and that will reduce amount that can be malloced even further.

With -N option amount of memory that can be allocated by malloc is expanded into 1st quadrant (which normally contains process text).

This can further be expanded to 3rd and 4th quadrant by chatr (+q3p and +q4p).

[Don Raman]

I tried -N option but now the tool crashes with bus error. Analyzed it with gdb and got the same traceback.

Can you tell the exact usage of chatr?

Regards,
Don.

[Don Raman]

I got the usage. Again the test program is working fine. let me see the actual prgram.

Regards,
Don.

[Don Raman]

My tool was already having -N option. But when I used +q3p it did work. Thanks a lot.

Again I would like to thank everyone involved here. You people are great!!!

Regards,
Don.

[Don Raman]

Thanks everyone for all the help and support.