__nullref problem?

[std::__nullref problem?]

Hello, All.

We are facing some issues while running our application. We are getting the exception; the trace is here.
#0 0x87ffffffed2fb090:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1
#1 0x87ffffffed21f2f0:0 in raise+0x30 () from /usr/lib/hpux64/libc.so.1
#2 0x87ffffffed2bcc70:0 in abort+0x190 () from /usr/lib/hpux64/libc.so.1
#3 0x87ffffffed649cf0:0 in std::terminate()+0x50 ()
from /usr/lib/hpux64/libCsup.so.1
#4 0x87ffffffed6492e0:0 in __cxa_personality_routine+0xa80 ()
from /usr/lib/hpux64/libCsup.so.1
#5 0x87ffffffed445180:0 in _Unwind_RaiseException+0x340 ()
from /usr/lib/hpux64/libunwind.so.1
#6 0x87ffffffed670ea0:0 in __cxa_throw+0x100 ()
from /usr/lib/hpux64/libCsup.so.1
#7 0x87ffffffef6fd7b0:2 in inline __rw::__rw_mutex_base::_C_acquire() ()
at /opt/aCC/include_std/rw/stdmutex.h:266
#8 0x87ffffffef6fd5e0:1 in inline __rw::__rw_guard::__rw_guard(__rw::__rw_mutex_base&) () at /opt/aCC/include_std/rw/stdmutex.h:493
#9 0x87ffffffef6fd5d0:1 in inline __rw::__rw_atomic_predecrement(long&,__rw::__rw_mutex_base&) () at /opt/aCC/include_std/rw/stdmutex.h:560
#10 0x87ffffffef6fd5d0:0 in inline __rw::__string_ref,std::allocator >::__removeReference() ()
at /opt/aCC/include_std/rw/string_ref:260
#11 0x87ffffffef6fd550:0 in inline std::basic_string,std::allocator >::_C_unlink() ()
at /opt/aCC/include_std/string:995
---Type to continue, or q to quit---
#12 0x87ffffffef6fd520:0 in inline std::basic_string,std::allocator >::~basic_string() ()
at /opt/aCC/include_std/string:361
#13 0x87ffffffef6fd510:0 in SOFAString::~SOFAString (this=0x87ffffffffffd1d8)
at source/sofastring.cpp:1180
#14 0x87ffffffed0e6920:0 in common::NameValueSet::Lexer::~Lexer (
this=0x87ffffffffffd1d0)

[where Lexer and SOFAString is our internal implementation. And SOFAString is derived from ustring]

By looking at this trace we are just wondering that whether it is related to with multiple __nullref references [is there any way to prove this in HP-UX - like LD_DEBUG in Solaris - We tried to use _HPDLDOPTS= .warnings. but some how we were not able to get the warnings? [Why we are suspecting the above trace may be due to because __nullref thing, if we some how bypass the above step we will end up getting core due to bad free - that too in the SOFA Destructor. And some documentation in the net pointed out that above symptom may be because of having multiple __nullref thing.]

So could you please tell us more about the above back trace and is it some thing related to using/not using some hp ux acc compiler setting and flags like -AA/ -AP etc - though we have ported our application to hp unix just now, we have used -mt, -AA consistently.

Thanks a lot in advance for all your help.

Thank you.

Best Regards,
Prasanna.

[std::__nullref problem?]

Just want to add another information. It is "single" threaded environment. It is the only one thread running.

[Dennis Handly]

>We are getting the exception; the trace is here.

Where is the "aCC runtime:" error message?
What version of the aC++ runtime are you using? What version of aC++ are you using?

>related to with multiple __nullref references

It's very possible. If you use any strings other than basic_string or basic_string, you are on your own!

>we have used -mt, -AA consistently.

This typically occurs because you didn't use -mt for every stinkin' aC++ object file.

>It is "single" threaded environment. It is the only one thread running.

You are confused. If you link in libpthread, it is multithreaded, period.

[Dennis Handly]

>ME: If you use any strings other than basic_string or basic_string, you are on your own!

Basically you'll need to go through every load module and figure out where the duplicate definitions of __nullref occur. Then pick a unique owner and "remove" the rest.

[std::__nullref problem?]

Thanks a lot for the reply.

We are using aCC version.
aCC: HP C/aC++ B3910B A.06.15 [May 16 2007]

Well. How can I verify that there are multiple nullref definition across libraries? can I rely on nm command - some thing like
-bash-3.2$ nm -p libmda_support.so | grep nullref | c++filt

0004611686018427986032 T __sinit__ZNSbItSt11char_traitsItESaItEE9__nullrefE()

0006917529027641096608 B guard of std::basic_string,std::allocator >::__nullref

0006917529027641096960 B std::basic_string,std::allocator >::__nullref

0000000000000000000000 U std::basic_string,std::allocator >::__nullref

0000000000000000000000 U std::basic_string,std::allocator >::__nullref


Is the above output say that there are multiple nullref things? is that above confirm that the problem is with multiple __nullref or is it some thing expected?

Also when I said single threaded I meant was there was only one thread running when we did info threads.

Thanks again for all your help again.

Thanks,
Prasanna.

[std::__nullref problem?]

One more information is, we are using â Wl,-B,symbolic this option. Some where in the document we have come across that it does not expose the global data to shared libraries. We feel it may be causing the problem. So is there any side effect in removing the -B, Symbolic option.

Thanks a lot in advance for all your help.

[Dennis Handly · Accepted solution]

>We are using aCC version. A.06.15

This version of aCC6 can't have that problem.

>How can I verify that there are multiple nullref definition across libraries?
nm -p libmda_support.so | grep nullref | c++filt

Well:
nm -pxAN libmda_support.so ... | fgrep _ZNSbItSt11char_traitsItESaItEE9__nullrefE

>B std::basic_string::__nullref
>Is the above output say that there are multiple nullref things?

You only have the one for unsigned short.

>is that above confirm that the problem is with multiple __nullref or is it something expected?

To have multiples, you need to look to other shlibs.

>when I said single threaded I meant was there was only one thread running

That doesn't matter.

>we are using -Wl,-B,symbolic this option.

You must NEVER use this option with C++!!
This creates multiple copies!

>We feel it may be causing the problem. So is there any side effect in removing the -B, Symbolic option.

Yes, this is probably the cause.
What side effect? Why was this added in the first place?

[std::__nullref problem?]

Thanks a lot. Looks like removing Symbolic option has solved the problem. Anyway we shall confirm and close this thread.

Thanks,
Prasanna.

[std::__nullref problem?]

We have wrongly used the -Wl -B Symbolic while building the C++ application as well. It should not have been. On removing that it is working as desired. Thanks to Dennis.