Core dump on HP PA-RISC

[porwaa]

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

[Steven E. Protter]

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

[Dennis Handly]

>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]

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]

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]

(gdb) print *__x

$1 = {_M_color = _S_red, _M_parent = 0x0, _M_left = 0x0, _M_right = 0x0}

[Dennis Handly]

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

[porwaa]

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]

>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]

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]

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]

>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]

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]

>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]

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

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

[porwaa]

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

[Dennis Handly]

>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]

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]

>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]

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]

>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]

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]

>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]

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]

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.