Problem with xlC

[Scott Nesbitt]

The following code cores on AIX 4.3.3 w/ VisualAge 5.0.2 and AIX 5.1
with VisualAge 6.0, but works fine on HP/UX, Solaris, and Linux.


#include <iostream>
#include <vector>

typedef struct WORK_ORDER_STRU
{
char field1[1024];
} TEST_STRU;

typedef std::vector<WORK_ORDER_STRU> Test_Vector;

int main()
{
Test_Vector fooStorage;
WORK_ORDER_STRU foo;

for (unsigned int i = 0; i < 50000; ++i)
{
fooStorage.push_back(foo);
}
}


$ xlC test.cpp
$ ./a.out
Abort(coredump)
$

Any suggestions? I was almost positive this was a bug in in
VisualAge, but then I installed gcc/g++ and got the same result. Now
I suspect a memory allocation bug in AIX.

Thanks,

Scott Nesbitt

 

[Victor Bazarov]

The following code cores on AIX 4.3.3 w/ VisualAge 5.0.2 and AIX 5.1
with VisualAge 6.0, but works fine on HP/UX, Solaris, and Linux.


#include <iostream>
#include <vector>

typedef struct WORK_ORDER_STRU
{
char field1[1024];
} TEST_STRU;

typedef std::vector<WORK_ORDER_STRU> Test_Vector;

int main()
{
Test_Vector fooStorage;
WORK_ORDER_STRU foo;

for (unsigned int i = 0; i < 50000; ++i)
{
fooStorage.push_back(foo);
}
}


$ xlC test.cpp
$ ./a.out
Abort(coredump)
$

Any suggestions? I was almost positive this was a bug in in
VisualAge, but then I installed gcc/g++ and got the same result. Now
I suspect a memory allocation bug in AIX.

How many 'foo' had you managed to push_back before it blew?
How much memory is allocated to your process on AIX? Is there
a limit? And, as you stated, it can easily be a problem in
the operating system...

Your code has nothing in it that would suggest that it should
not work, except that 'push_back' can throw 'std::bad_alloc'
(which you're not catching), and since you're not catching it,
the program is allowed to terminate abnormally.

Shortage of available memory is a problem with many programs,
yours is no exception. How that shortage comes about is not
really a language problem, try asking in an AIX newsgroup.

Also, you're not using anything from <iostream>, do you really
need to include it (not that it should make any difference)?
Try removing it and compare the coredumps, see if you get any
farther in the loop... BTW, did you know that you could load
the dumped core into a debugger to see the state of your
program at the time of the failure? I am not sure it's going
to help, but do try it.

Victor