Programs that link to Oracle core dump on 11.11

[John McGee]

We have a set of programs that link to Oracle libraries and work fine on 11.23. Now we've moved the source code to 11.11 and recompiled everything with aCC 3.63. When we try to run any of the programs on 11.11, a core dump occurs even before the first line of code executes. We have created a simple test program (with just a printf) that has the same problem, but the program has to link to all of our libraries as well as Oracle's libclntsh.sl for the core dump to occur.

Now we've discovered the same problem occurs when we try to run a program that links to our libraries and a QT library, so it looks like it's not just a problem with Oracle.

To get our code to compile and link successfully, we had to use the -AA flag. We are wondering if that is causing a problem when we try to link to third-party libraries, but we can't seem to confirm that. I don't see any of the -AP libraries listed when I do "ldd" on my executables.

I'd appreciate any suggestions on how we can fix this problem.

[A. Clay Stephenson]

I would compile everything with the -g option to include debugging and then allow the program to die. You should then be able to easily examine the core via with gdb and do a stack trace to identify the problem.

[John McGee]

Thanks for the response.

I have been compiling with -g.

When I use RunDDD and run the program until it dies, I get the following error message:

Program received signal SIGABRT, Aborted
si_code: 0 - SI_UNKNOWN - signal of unknown origin.
0x77f9dee0 in kill+0x10 () from /usr/lib/libc.2

Here is what backtrace shows:

#11 0x77e74b58 in _main+0x100 () from /usr/lib/libCsup_v2.2
#10 0x77e74828 in __mainHelper+0x40 () from /usr/lib/libCsup_v2.2
#9 0x165298 in std::__sinit_Process_C+0x3c ()
#8 0x77dd6194 in std::ios_base::Init::Init+0x1df0 () from /usr/lib/libstd_v2.2
#7 0x77dd66cc in std::ios_base::setf+0x78 () from /usr/lib/libstd_v2.2
#6 0x77e71254 in __throw__FPvT1+0x14c () from /usr/lib/libCsup_v2.2
#5 0x77e70cf4 in ThrowException+0x70 () from /usr/lib/libCsup_v2.2
#4 0x77e7083c in std::terminate+0x38 () from /usr/lib/libCsup_v2.2
#3 0x77f78b24 in abort+0x1c () from /usr/lib/libc.2
#2 0x77f78ac8 in abort_C+0x160 () from /usr/lib/libc.2
#1 0x77f3716c in raise+0x24 () from /usr/lib/libc.2
#0 0x77f9dee0 in kill+0x10 () from /usr/lib/libc.2

I'm not sure what this is telling me. Can you provide any more help?

[A. Clay Stephenson]

Okay, I think I know what's wrong. All least some of your libraries were compiled using -AA. -AA is all or nothing; every object has to be compiled with this flag or none of them.

The man page for aCC makes it rather clear:
/quote/
NOTE: Objects and libraries compiled with -AA are binary incompatible with objects and libraries compiled without -AA.
/unquote/

At least you can get the source for Qt so that if necessary, you can build the libraries to match Oracle's apparent use of -AA.

[John McGee]

Thanks again for your response.

We have been compiling all of our libraries with -AA because we got compile errors if we didn't. We've also been linking our executables using -AA.

Do you think the problem is that Oracle's library isn't compiled with -AA?

I checked Oracle's libclntsh.sl with ldd, and I don't see any libraries in it that are listed as being either -AA (_v2.) or -AP (libstream., libstd., librwtool., or libCsup.). I also checked my executable with ldd, and I only see the -AA libraries in it.

[Ermin Borovac · Accepted solution]

Not sure if it'll help but try recompiling executable and your libraries with -mt aCC option.

-mt Sets various -D flags to enable multi-threading. Also
sets -lpthread. For details see HP aC++ Online
Programmer's Guide.

Oracle's libclntsh.sl pulls in libpthread and that can result in core dump if -mt option is not used. This applies even if your program is not using any MT related calls.

[John McGee]

Thank you very much for the "-mt" hint! It looks like that has fixed our problem. I recompiled all of our libraries and executables with -mt, and now I don't get the core dump error (at least in the executables I've been able to test so far).

I do have a couple of questions related to this:

1. The problem went away when I recompiled everything with -mt, but the linking is still being done without -mt. So far I haven't seen a difference in programs linked with or without -mt (as long as they are compiled with -mt). Would you recommend also including the -mt in the link line?

2. Can you offer any explanation for why the -mt would be needed on 11.11 but not 11.23? I'm using aCC 3.63 (with -AA) on 11.11 and aCC 5.55 (without -AA) on 11.23 to compile the same source code.

Thanks again for helping me with this!

[Ermin Borovac]

1. aCC -mt flag defines some preprocessor flags and adds -lpthread to the linking stage. It's a compiler flag and linker wouldn't understand it.

To see what preprocessor flags are defined run aCC with '-mt -v' (-v for verbose). These flags are defined to make your library calls thread-safe. I think that you must use -mt with aCC if you are linking with libpthread (implicitly in your case through oracle library).

2. Really don't know why. aCC 5.55 must be using -AA by default or otherwise your code wouldn't compile. You can check this by looking at the man page for aCC or check for existance of _HP_NAMESPACE_STD macro in aCC -v output. If you see -D_HP_NAMESPACE_STD in aCC -v it means -AA is on.

In any case you can't go wrong with -mt.

[John McGee]

Thanks for the additional information.

According to some documentation from HP, -AA is the default for Itanium/11.23 systems but not for PA-RISC/11.11 systems, so that explains why I need to use -AA on our 11.11 system. I'm still not sure why I need to use -mt on 11.11 but not 11.23, but I suppose I can just go with what works for now.

[John McGee]

Compiling with -mt has fixed this problem.