Core Dump with multi-threaded application...

[Sanjay Sutar]

>>(By point, I meant add a comment saying "look here <<<".)

Thanks for clarifying that :)

>>You can use chatr(1) to see what the paths are. If you embed a path, it can point to somewhere different. And you can also use SHLIB_PATH to change it.

I have both embedded path and SHLIB_PATH eanbled, the embeded path is ../lib:. and SHLIB_PATH is also ../lib, and I can see from the ldd output that the exe is pointing to correct lib files on the test machine.

Just one point I want to highlight, I get core dump even when I use cout , so I dont think this is just about static varibles initialization.

>>I sent him a pointer to this thread.

Thank you so much for that.

[Steve Ellcey]

Looking at the ldd output there are two things that concern me, one is the duplicate listings for the libstdc++.sl and libgcc_s.sl libraries. Since you are using a GCC from /usr/local, you should be using the libstdc++ and libgcc_s libraries from /usr/local/lib, not ones from your home directory. A mismatch there could cause problems. The other thing I noticed is that you are using GCC 3.4.2. The latest release of GCC is 4.1.1 (with 4.1.2 out soon). Recompiling with a newer GCC might help, but you need to compile everything. Mixing code from GCC 3.4.* and GCC 4.* may not work well. One last suggestion would be to make sure you have the latest HP linker patch on your system, we have had some linker issues in the past though I believe those were with the 64 bit mode and not with the 32 bit mode.

[Sanjay Sutar]

>> you should be using the libstdc++ and libgcc_s libraries from /usr/local/lib, not ones from your home directory.

I did that, again I copied the libstdc++.sl.6 and libgcc_s.sl files from the build machine to test machine but it didnt helped.

>> you are using GCC 3.4.2. The latest release of GCC is 4.1.1 (with 4.1.2 out soon)

We cant use the latest gcc as we have dependancy on other component which are built with gcc 3.4.2.


>>One last suggestion would be to make sure you have the latest HP linker patch on your system

Could you please suggest the neccessary patch.
Here is the dump of swlist output.

# Contacting target "kelp"...
#
# Target: kelp:/
#

#
# Bundle(s):
#

BUNDLE B.11.11 Patch Bundle
BUNDLE11i B.11.11.0102.2 Required Patch Bundle for HP-UX 11i, February 2001
Base-VXVM B.03.20.1 Base VERITAS Volume Manager 3.2 for HP-UX
CDE-ChineseS B.11.11 Simplified Chinese CDE Environment
CDE-ChineseT B.11.11 Traditional Chinese CDE Environment
CDE-English B.11.11 English CDE Environment
CDE-French B.11.11 French CDE Environment
CDE-German B.11.11 German CDE Environment
CDE-Italian B.11.11 Italian CDE Environment
CDE-Japanese B.11.11 Japanese CDE Environment
CDE-Korean B.11.11 Korean CDE Environment
CDE-Spanish B.11.11 Spanish CDE Environment
CDE-Swedish B.11.11 Swedish CDE Environment
FDDI-00 B.11.11.02 PCI FDDI;Supptd HW=A3739A/A3739B;SW=J3626AA
FibrChanl-00 B.11.11.09 PCI/HSC FibreChannel;Supptd HW=A6684A,A6685A,A5158A,A6795A
GigEther-00 B.11.11.14 PCI/HSC GigEther;Supptd HW=A4926A/A4929A/A4924A/A4925A;SW=J1642AA
GigEther-01 B.11.11.04 PCI GigEther;Supptd HW=A6794A/A6825A/A6847A
HPUX11i-MTOE B.11.11.0206 HP-UX Minimal Technical OE Component
HPUXBase64 B.11.11 HP-UX 64-bit Base OS
HPUXBaseAux B.11.11.0206 HP-UX Base OS Auxiliary
HWEnable11i B.11.11.0206.5 Hardware Enablement Patches for HP-UX 11i, June 2002
OnlineDiag B.11.11.07.11 HPUX 11.11 Support Tools Bundle, Jun 2002
RAID-00 B.11.11.01 PCI RAID; Supptd HW=A5856A
perl B.5.6.1.C Perl Programming Language
#
# Product(s) not contained in a Bundle:
#

DebugPrg B.11.11.14 Debugging Support Tools
PHNE_30695 1.0 telnet kernel, telnetd(1M), telnet(1) patch
WDB B.11.11.14 HP Wildebeest (HP WDB) Debugger

[Dennis Handly · Accepted solution]

>Could you please suggest the neccessary patch.

I don't see any installed. The latest is PHSS_35379.

[Sanjay Sutar]

Finally, this patch did the trick!!!

Dennis, Steve, Peter,
Thanks for your assistance!!!!

Steve ,
what made you to think that this issue will need the linker patch? I am just wondering the solution seems so simple but it took very long to figure it out.

Thanks again for your assistance.

[Dennis Handly]

>what made you to think that this issue will need the linker patch?

Static construction with g++ depends on linker features. Static construction with aC++ PA32 predates these features, so it doesn't matter. And I usually assume people have something recent.

And Steve works with g++ and probably remembers when they were introduced.

Lack of .init support would cause those globals to still be zero. If I had your executable in my hands, I would have eventually figured it out.

[Sanjay Sutar]

Nice explaination !!

>> I would have eventually figured it out.

If possible, would you please explain , how?
That will help me/other people who face the issue to check the issue on our own.

[Dennis Handly]

>If possible, would you please explain, how?
>That will help me/other people who face the issue to check the issue on our own.

I'll try. :-)

Your executable may just work on my system because I have that ld/dld patch. That would be a clue. (Did you try moving the executable and have it work on one machine and fail on another?)

Your executable probably has the .init data in $SHORTDATA$INIT$ subspace and .fini in $SHORTDATA$FINI$ because your g++ is new enough.

You can see these with /usr/ccs/bin/odump -sub. You can see the init/fini counts with odump -sldlheaderext

So if you see the subspaces but no counts, it says you have an old linker. If you see the counts but they don't work, it means you have copied from a good system and trying to run on a system with an old dld.