core dump in pthread_mutex_destroy on startup?

core dump in pthread_mutex_destroy on startup?

Post by Rich Stephe » Fri, 02 Aug 2002 01:14:46



I am having a problem with my application that was compiled on HPUX
11.11.  It works wonderfully on our HPUX 11.11 machine, but when
attempting to run it on two different HPUX 11.00 (Note the ".00" vs
".11")
machines, the executable core dumps before ever reaching main().

The stack trace is as follows:

#0  0xc0ebc884 in pthread_mutex_destroy () from /usr/lib/libpthread.1
(gdb) where
#0  0xc0ebc884 in pthread_mutex_destroy () from /usr/lib/libpthread.1
#1  0xc0205cb8 in __thread_mutex_free () from /usr/lib/libc.2
#2  0xc1735470 in _HPMutexWrapper::~_HPMutexWrapper () from
/usr/lib/libstd_v2.2
#3  0x22af4c in __dt__Q2_4__rw12__string_refXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__Fv
()
   from /usr/work/ecibin77/./xserver
#4  0x22a70c in _C_getRep__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FUlT1
()
   from /usr/work/ecibin77/./xserver
#5  0xc16a28b8 in std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string<char,std::char_traits<char>,std::allocator<char>>
() from /usr/lib/libstd_v2.2
#6  0xc16fea08 in std::locale::name () from /usr/lib/libstd_v2.2
#7  0xc16a1bd0 in std::ctype<char>::_C_initfacet () from
/usr/lib/libstd_v2.2
#8  0xc16ff1ec in std::locale::_C_install_facet () from
/usr/lib/libstd_v2.2
#9  0xc16fef64 in std::locale::_C_make_facet () from
/usr/lib/libstd_v2.2
#10 0xc16f97cc in std::ios_base::Init::Init () from
/usr/lib/libstd_v2.2
#11 0x22bad4 in __sinit_FormDrawCpp_cpp___3stdFv () from
/usr/work/ecibin77/./xserver
#12 0xc0df762c in __mainHelper () from /usr/lib/libCsup.2
#13 0xc0df79d4 in _main () from /usr/lib/libCsup.2

I was wondering if anyone on an HPUX 11.00 machine had come across
this problem before (either related to ICU or not) and could suggest
any possible solutions.

I have already tried recompiling the application on the aforementioned
11.00 machine,as well as applying patches to the aCC and ANSI C
compilers and the pthread libraries.

If anyone has any ideas, I would be eternally grateful.

 
 
 

core dump in pthread_mutex_destroy on startup?

Post by Dennis Hand » Sat, 03 Aug 2002 22:44:33


: the executable core dumps before ever reaching main().
: #0  0xc0ebc884 in pthread_mutex_destroy () from /usr/lib/libpthread.1
: #1  0xc0205cb8 in __thread_mutex_free () from /usr/lib/libc.2
: #10 0xc16f97cc in std::ios_base::Init::Init () from

: I was wondering if anyone on an HPUX 11.00 machine had come across
: this problem before

As I mentioned in cxx-dev, you need to compile with the right -D flags.
Use -mt so you'll get it right.

 
 
 

core dump in pthread_mutex_destroy on startup?

Post by eric_hamil.. » Sun, 04 Aug 2002 02:22:37


: I am having a problem with my application that was compiled on HPUX
: 11.11.  It works wonderfully on our HPUX 11.11 machine, but when
: attempting to run it on two different HPUX 11.00 (Note the ".00" vs
: ".11")
: machines, the executable core dumps before ever reaching main().

Compiling or linking on a later version of HP-UX and then running on an
earlier version of HP-UX is not supported and frequently does not work.  I
don't know if that's what is causing this particular failure, but it will
bite you eventually.

HP-UX offers a good deal of binary compatibility in terms of taking
applications built on earlier releases and running them on later releases.
If you need your program to run on both 11.00 and 11.11 you should build it
on 11.00 and follow the compatibility guidelines.

For a fuller description of the HP-UX Compatibility criteria see

http://devresource.hp.com/STK/partner/compat.html#Compile

Eric Hamilton
HP-UX kernel lab

 
 
 

1. newgrp sets core dump size limit to 0 on HP-UX 11

Hello,

I noticed today that using newgrp(1) on HP-UX 11.0 and 11.i results in the
hard limit for core dump size getting set to 0:

        hp% uname -a
        HP-UX hp B.11.11 U 9000/780 unknown
        hp% limit coredumpsize 12345
        hp% limit coredumpsize
        coredumpsize    12345 kbytes
        hp% limit -h coredumpsize
        coredumpsize    unlimited

        hp% newgrp users
        hp% limit coredumpsize
        coredumpsize    0 kbytes
        hp% limit -h coredumpsize
        coredumpsize    0 kbytes

Since it sets the hard limit to 0, it is not possible for to create a core
dump under any circumstances after running newgrp.

This seems to be hard coded in the newgrp binary, I did a system call
trace using tusc:

        # tusc /usr/bin/newgrp

        ... snip ...
        setrlimit(RLIMIT_CORE, 0x680f0804) ....................... = 0
        setgid(3) ................................................ = 0
        setresuid(0, 0, 0) ....................................... = 0
        setresuid(0, 0, 0) ....................................... = 0
        getpid() ................................................. = 21227 (21226)
        audwrite(0x680f0874) ..................................... = 0
        audswitch(0) ............................................. = 0
        setuid(0) ................................................ = 0
        execve("/sbin/sh", 0x680f0878, 0x680f0674) ............... = 0 [32-bit]
        ...

Note the call to setrlimit() right before it exec()s the shell.

/usr/bin/newgrp on HP-UX 10.20 does not seem to have this behavior. It
preserves the existing limits as you'd expect, and doesn't call
setrlimit(). However, 11.0 and 11.i both do.

Does anyone know if this is a feature or a bug?

Thanks,

Chris Wing

2. after installing frontpage server extension

3. core dump size means what?

4. Arcserve vs. iwsp5a

5. Core Dump

6. xml as database

7. core dump while declaration of Object

8. Help configuring a DECserver 700 for PPP

9. core dump analysis

10. How to initiate manual core dump in HPUX

11. forcing core dumps on HPUX

12. Reg. core dump in hpux

13. SAM core dump when getting list of users