1833108 Members
2683 Online
110051 Solutions
New Discussion

Core dump on HP PA-RISC

 
porwaa
Advisor

Core dump on HP PA-RISC

I'm getting a core dump like below. This happens when my application is executing the C++ new instruction.
Why is tree.cc being found at /tmp/gcc-4.2.1.tar.gz/gcc-4.2.1/libstdc++-v3/src/tree.cc. Is that the reason for failure or something else has to be picked.

#0 0xc54bbd64 in _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base (__x=0x77e2e574) at /tmp/gcc-4.2.1.tar.gz/gcc-4.2.1/libstdc++-v3/src/tree.cc:94
94 /tmp/gcc-4.2.1.tar.gz/gcc-4.2.1/libstdc++-v3/src/tree.cc: No such file or directory.
(gdb) where
#0 0xc54bbd64 in _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base (__x=0x77e2e574) at /tmp/gcc-4.2.1.tar.gz/gcc-4.2.1/libstdc++-v3/src/tree.cc:94
#1 0xc618d2d0 in _ZNSt17_Rb_tree_iteratorISt4pairIKP6StringPN2IR3XML7MessageEEEmmEv (this=) at /opt/hp-gcc-4.2.1/include/c++/4.2.1/bits/stl_tree.h:198
#2 0xc618d878 in _ZNSt8_Rb_treeIP6StringSt4pairIKS1_PN2IR3XML7MessageEESt10_Select1stIS8_EN6extstl12DerefCompareIS0_EESaIS8_EE16_M_insert_uniqueERKS8_ (this=,
__v=@0x779c1948) at /opt/hp-gcc-4.2.1/include/c++/4.2.1/bits/stl_tree.h:988
#3 0xc618da44 in _ZNSt3mapIP6StringPN2IR3XML7MessageEN6extstl12DerefCompareIS0_EESaISt4pairIKS1_S5_EEE6insertERKSB_ (this=, __x=@0x779c1948)
at /opt/hp-gcc-4.2.1/include/c++/4.2.1/bits/stl_map.h:400
#4 0xc618db90 in _ZN6extstl9ExtPtrMapI6StringN2IR3XML7MessageENS_12DerefCompareIS1_EEE17insertKeyAndValueEPS1_PS4_ (this=, key=0x402cc808, a=0x402a8b58)
at ../../../share/utils/hp800_v1111_S/header/ext_stl/ext_ptr_map.h:206

 

P.S. This thread has been moved from HP-UX Technical Documentation to HP-UX > languages. -HP Forum Moderator

26 REPLIES 26
Steven E. Protter
Exalted Contributor

Re: Core dump on HP PA-RISC

Shalom,

My best estimate is that SHLIB_PATH was not set to the correc ocation of tree.cc when the compile was done.

You may have the wrong library compiled into your binary, causing the issue in this case.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>I'm getting a core dump like below.

You need to debug the problem.

>Why is tree.cc being found at /tmp/gcc-4.2.1.tar.gz/.../tree.cc?

As Steven said, that may be where it was when it was compiled?
You'll need to use gdb's dir command to add the path to the header directory.
porwaa
Advisor

Re: Core dump on HP PA-RISC

This is further information on the register information and disassembly.

(gdb) info reg
flags: 2f000041 r18: 0 pcsqt: 4fa1800 ccr: 0
r1: 4fa1800 r19: 77f97428 eiem: ffffffff cr12: 0
rp: c4f8d2db r20: 0 iir: f881094 cr13: 0
r3: 779b3b40 r21: 779b3b40 isr: 1723400 cr24: 0
r4: 77debf58 r22: 0 ior: 4 cr25: 0
r5: 77e31570 r23: 1 ipsw: 6ff1f cr26: 0
r6: 4afe5040 r24: 779b3914 goto: 0 mpsfu_high: 401fa400
r7: 80 r25: 779b3a88 sr4: 1723400 mpsfu_low: 0
r8: 3 r26: 77e31574 sr0: 4fa1800 mpsfu_ovfl: 0
r9: 1 dp: 4004cea0 sr1: 0 pad: 0
r10: dee8a8 ret0: 0 sr2: 0 fpsr: 8200000
r11: 1878000 ret1: 0 sr3: 0 fpe1: 0
r12: ffff0000 sp: 779b3b40 sr5: fa55800 fpe2: 0
r13: 0 r31: 1 sr6: 4fa1800 fpe3: 0
r14: 1 sar: 10 sr7: 4fa1800 fpe4: 0
r15: cffb60 pcoqh---Type to continue, or q to quit---
: c1cbba1c cr0: 0 fpe5: 0
r16: cfc1f8 pcsqh: 4fa1800 cr8: 0 fpe6: 0
r17: 0 pcoqt: c1cbba20 cr9: 0 fpe7: 0
(gdb)


(gdb) disas $pc-4*16 $pc+4*4
Dump of assembler code from 0xc1cbb9dc to 0xc1cbba2c:
;;; File: ../../../../gcc-4.2.1/libstdc++-v3/src/tree.cc
;;; _Rb_tree_increment(const _Rb_tree_node_base* __x)
0xc1cbb9dc <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+4>:
stw,ma %r4,0x40(%sp)
;;; return _Rb_tree_increment(const_cast<_Rb_tree_node_base*>(__x));
0xc1cbb9e0 <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+8>:
b,l 0xc1cbb9bc <_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base>,%rp
0xc1cbb9e4 <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+12>:
stw %r19,-0x20(%sp)
;;; }
0xc1cbb9e8 <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+16>:
ldw -0x54(%sp),%rp
0xc1cbb9ec <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+20>:
bv %r0(%rp)
0xc1cbb9f0 <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+24>:
ldw,mb -0x40(%sp),%r4
0xc1cbb9f4 <_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+28>:
break 0,0
;;; if (__x->_M_color == _S_red
0xc1cbb9f8 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base>:
b,l 0xc1cbba10 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base>,%rp
0xc1cbb9fc <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+4>: nop
---Type to continue, or q to quit---
0xc1cbba00 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+8>:
ldw -0x18(%sp),%rp
0xc1cbba04 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+12>:
ldsid (%rp),%r1
0xc1cbba08 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+16>:
mtsp %r1,%sr0
0xc1cbba0c <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+20>:
be,n 0(%sr0,%rp)
0xc1cbba10 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base>:
ldw 0(%r26),%ret0
0xc1cbba14 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+4>:
cmpib,<>,n 0,%ret0,0xc1cbba24 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+20>
0xc1cbba18 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+8>:
ldw 4(%r26),%ret0
0xc1cbba1c <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+12>:
ldw 4(%ret0),%r20
0xc1cbba20 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+16>:
cmpb,=,n %r26,%r20,0xc1cbba50 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+64>
;;; else if (__x->_M_left != 0)
0xc1cbba24 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+20>:
ldw 8(%r26),%ret0
0xc1cbba28 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+24>:
cmpib,<>,n 0,%ret0,0xc1cbba38 <_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+40>
End of assembler dump.


(gdb) p /x $sp_save = $sp
$1 = 0x779b3b40

==================================

(gdb) frame 11
#11 0xc0055574 in __pthread_start () from /usr/lib/libpthread.1

===================================


(gdb) p $sp - $sp_save
$2 = -2752

========================
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

Please copy your details (and attachment) from your other thread to this thread.
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1332124

Not much can be determined. A call to std::_Rb_tree_decrement is being passed a pointer to a node that looks like both the left and right node is 0.
0xc1cbba1c: ldw 4(%ret0),%r20
And ret0 is 0.

Can you: print *x

porwaa
Advisor

Re: Core dump on HP PA-RISC

(gdb) print *__x

$1 = {_M_color = _S_red, _M_parent = 0x0, _M_left = 0x0, _M_right = 0x0}
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

Your RB tree has become corrupted.
Have you compiled your application with thread safe options?
porwaa
Advisor

Re: Core dump on HP PA-RISC

Thanks. Do you mean that -pthread option should have been used while compiling on HP PA-RISC system.
Do we also need to use --enable-threads=posix compile time option.
Is this also something to do with TLS? This application is a multi threaded application.

Is it that GCC only allows thread local storage if it sees that the assembler being used also supports it. The 2.17 GNU assembler did not support thread local storage on PA and that is why GCC is not allowing it (even if compiled with --enable-threads=posix. The 2.18 GNU assembler has just recently been released and that assembler does allow thread local storage.
How to check this is this applies?
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>Do you mean that -pthread option should have been used while compiling on HP PA-RISC system. Do we also need to use --enable-threads=posix compile time option?

Most likely.

>Is this also something to do with TLS? This application is a multi threaded application.

I'm not sure. You don't need TLS for a thread safe map/set/rbtree.

>How to check this is this applies?

If you check your g++ link, it mentions sending gcc questions to gcc-help@cup.hp.com.
porwaa
Advisor

Re: Core dump on HP PA-RISC

Still we are not past the crash. The rbtree is getting coruupted. I tried removing the -lCsup_v2 linker option which I guess does not go with g++.
porwaa
Advisor

Re: Core dump on HP PA-RISC

The crash is happening ta the line
if (__x->_M_color == _S_red
in the below function
_Rb_tree_node_base*
_Rb_tree_decrement(_Rb_tree_node_base* __x)
{
if (__x->_M_color == _S_red
&& __x->_M_parent->_M_parent == __x)
__x = __x->_M_right;
else if (__x->_M_left != 0)
{
_Rb_tree_node_base* __y = __x->_M_left;
while (__y->_M_right != 0)
__y = __y->_M_right;
__x = __y;
}
else
{
_Rb_tree_node_base* __y = __x->_M_parent;
while (__x == __y->_M_left)
{
__x = __y;
__y = __y->_M_parent;
}
__x = __y;
}
return __x;
}
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>I tried removing the -lCsup_v2 linker option which I guess does not go with g++.

That's correct, it is illegal to mix aC++ with g++.

>The crash is happening the the line: if (__x->_M_color == _S_red

Actually on this part:
&& __x->_M_parent->_M_parent

There is nothing further we can do about the problem unless you port to aC++ and have a support contract. And you would likely have to pay for time and materials.

Your RBtree is corrupted or you aren't pointing at a valid map. You would need tools to walk the whole tree to see when & where this is happening. Then you can use a hardware watch point to catch the problem.
porwaa
Advisor

Re: Core dump on HP PA-RISC

This is ahppening at the first call to insert into a map. The map has two members which are allocated on the heap by new.
Note that this code works fine on linux when build with GCC.
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>This is happening at the first call to insert into a map. The map has two members which are allocated on the heap by new.

How can it have two members if it is the first call to insert?

>Note that this code works fine on linux when build with GCC.

Are you using the same g++ version? Have you linked with -z, so it aborts sooner?
porwaa
Advisor

Re: Core dump on HP PA-RISC

It is something like this.
static Map > object; ---->declaration

object.insertKeyAndValue(new String(IR_MSG),
new IR_msg_1());
porwaa
Advisor

Re: Core dump on HP PA-RISC

I could not find documentation on the -z option. How does it help?
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>It is something like this.
static Map > object; ->declaration

This is also a definition.

object.insertKeyAndValue(new String(IR_MSG),
new IR_msg_1());

I assume that the result of the two news is valid? Should I worry about IR_msg_1 vs IR_mes?

>I could not find documentation on the -z option. How does it help?

It is a linker option. It prevents dereferencing of NULL pointers.
http://docs.hp.com/en/B2355-60130/ld_pa.1.html
porwaa
Advisor

Re: Core dump on HP PA-RISC

Thanks.

If the deferencing of NULL pointer is restricted through the -z option, does it lead to some kind of unpredictable results. Does it mean, that the option shall be as good as commenting those pieces of code that produce a NULL pointer deference at run time?

Will it be adviasable to do this given that the rbtree was getting corrupted?
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>Does it mean, that the option shall be as good as commenting those pieces of code that produce a NULL pointer deference at run time?

No, it causes an abort. Perhaps this may find your bug?

>Will it be advisable to do this given that the rbtree was getting corrupted?

-z doesn't hide the problem, it will report the problem.

Hmm, I just remembered that since you are already aborting on a NULL pointer, g++ sets -z by default.
porwaa
Advisor

Re: Core dump on HP PA-RISC

I think -Z in upper case is the default options.
Do you mean -z and -Z are one and the same.
If it is then it was already accounted and we are deferecing the NULL pointer.
Is it good to edit the tree.cc rb decrement function in such a way that the code to deference a pointer is skipped if the pointer is NULL.
Experts please let me know your comments.
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>I think -Z in upper case is the default options.

Not for g++. (I made the same assumption here before. Use g++ -v to check.) It insists you be a good programmer. ;-)

>it was already accounted and we are dereferencing the NULL pointer.

Yes.

>Is it good to edit the tree.cc rb decrement function in such a way that the code to deference a pointer is skipped if the pointer is NULL?

I wouldn't think so. The code should already be checking for root nodes. And the m_parent entry shouldn't be 0.
porwaa
Advisor

Re: Core dump on HP PA-RISC

What do you suggest as the last option here.
Given that the code is tunning on Linux GCC it definitely looks like a compiler/linker options issue.
Dennis Handly
Acclaimed Contributor

Re: Core dump on HP PA-RISC

>What do you suggest as the last option here?

Do you have a fairly recent linker patch installed?

>Given that the code is running on Linux GCC it definitely looks like a compiler/linker options issue.

Can you isolate the problem to a non-threaded application?
porwaa
Advisor

Re: Core dump on HP PA-RISC

Yes the latest linker pathc was installed.

I think it would be a good idea to segregate the problem into a slandlone app and reproduce the error.
porwaa
Advisor

Re: Core dump on HP PA-RISC

Does a memory debugger help here. Purify etc..
The rb tree is getting corrupted. What kind of a memory error htis could be and how purify can help.