SIGSEGV unless shared library mapped private enabled

[Jack Kidwell]

My application runs fine under dbg, when "chatr +dbg enable", or when "pxdb -s on". Otherwise, it dies in libc.2. Here's a backtrace on the core:

(gdb) bt
#0 ... in .stub+0x190 () from /usr/lib/pa20_64/libc.2
#1 ... in __nsw_getoneconfig+0x6d0 ()
from /usr/lib/pa20_64/libc.2
#2 ... in __nsw_getconfig+0xcc () from /usr/lib/pa20_64/libc.2
#3 ... in .stub+0x130 () from /usr/lib/pa20_64/libc.2
#4 ... in nss_search+0x98 () from /usr/lib/pa20_64/libc.2
#5 ... in gethostbyaddr+0x13c () from /usr/lib/pa20_64/libc.2
#6 ... in hostaccess (sin=0x800003fffeedc23c) at tcpwrap.c:94
#7 ... in do_accept (fd=3) at socket_worker.c:519
#8 ... in socket_worker (arg=0x0) at socket_worker.c:303
#9 ... in __pthread_create_system+0x440 ()
from /usr/lib/pa20_64/libpthread.1

As a workaround, I'm using chatr to force private shared libraries.

# uname -a
HP-UX ... B.11.00 U 9000/785 HP-UX

Thank you.

[Dennis Handly]

(11.00 isn't supported.)

This likely means that the program is trying to write to a readonly variable.

After it aborts, what does this show?
(gdb) info reg
(gdb) disas $pc-4*12 $pc+4*8

[Jack Kidwell]

(gdb) info reg
flags: 2f000041
r1: 800003fffef2e740 rp: c0000000004c8703 r3: 800003fffeedc290 r4: 800003fffeedc810 r5: 80000001003d7bb0 r6: 0
r7: 0 r8: 0 r9: 0 r10: 0 r11: 0 r12: 0
r13: 0 r14: 0 r15: 0 r16: 0 r17: 0 r18: 0
r19: c000000000431618 r20: 38e6eff0 r21: 4 r22: 800003fffef2dd80 r23: 121 r24: c000000000431620
r25: 1 r26: c000000000431618 dp: 800003fffef2df40 ret0: 0 ret1: 800003fffeedc810 sp: 800003fffeedc990
r31: 800003fffef34420 sar: 1c pcoqh: c0000000004c8ba8 pcsqh: bd68c00 pcoqt: c0000000004c8bac pcsqt: bd68c00
eiem: ffffffffffffffff iir: 52940000 isr: a780800 ior: 38e6eff0 ipsw: ff0804ff1f goto: 0
sr4: a780800 sr0: bd68c00 sr1: 0 sr2: 0 sr3: 0 sr5: bdb4c00
sr6: a17e800 sr7: bd68c00 cr0: 0 cr8: 0 cr9: 0 ccr: 0
cr12: 0 cr13: 0 cr24: 0 cr25: 0 cr26: 0 mpsfu_high: 80000001003d7bb0
mpsfu_low: 0 mpsfu_ovfl: 0 pad: 205130ad205130ad fpsr: 800000000000000 fpe1: 0 fpe2: 0
fpe3: 0
(gdb) disas $pc-4*12 $pc+4*8
Dump of assembler code from 0xc0000000004c8b78 to 0xc0000000004c8bc8:
0xc0000000004c8b78 <.stub+352>: ldo 8(%r19),%r19
0xc0000000004c8b7c <.stub+356>: movb,tr %r0,%r5,0xc0000000004c8c18 <.stub+512>
0xc0000000004c8b80 <.stub+360>: copy %r5,%ret0
0xc0000000004c8b84 <.stub+364>: addil L'0x800,%dp,%r1
0xc0000000004c8b88 <.stub+368>: copy %r1,%r19
0xc0000000004c8b8c <.stub+372>: ldd 0x340(%r19),%r19
0xc0000000004c8b90 <.stub+376>: std %r19,-0x90(%sp)
0xc0000000004c8b94 <.stub+380>: ldd -0x90(%sp),%r19
0xc0000000004c8b98 <.stub+384>: cmpib,*= 0,%r19,0xc0000000004c8c10 <.stub+504>
0xc0000000004c8b9c <.stub+388>: nop
0xc0000000004c8ba0 <.stub+392>: ldd -0x40(%r4),%r19
0xc0000000004c8ba4 <.stub+396>: ldd -0x90(%sp),%r20
0xc0000000004c8ba8 <.stub+400>: ldd 0(%r20),%r20
0xc0000000004c8bac <.stub+404>: ldd 8(%r20),%r20
0xc0000000004c8bb0 <.stub+408>: copy %r19,%r26
0xc0000000004c8bb4 <.stub+412>: copy %r20,%r25
0xc0000000004c8bb8 <.stub+416>: call 0xc00000000043d590 <.stub>
0xc0000000004c8bbc <.stub+420>: ldo -0x30(%sp),%ret1
0xc0000000004c8bc0 <.stub+424>: ldd -0x138(%sp),%dp
0xc0000000004c8bc4 <.stub+428>: cmpib,<> 0,%ret0,0xc0000000004c8bf8 <.stub+480>
0xc0000000004c8bc8 <.stub+432>: nop
End of assembler dump.

[Dennis Handly]

r20: 38e6eff0
0xc0000000004c8ba4 <.stub+396>: ldd -0x90(%sp),%r20
0xc0000000004c8ba8 <.stub+400>: ldd 0(%r20),%r20 <<
0xc0000000004c8bac <.stub+404>: ldd 8(%r20),%r20
0xc0000000004c8bb4 <.stub+412>: copy %r20,%r25

R20 has a bad address. This is stored in a local, $sp-0x90.

There is nothing here that indicates it is trying to write to a readonly variable. It seems something has been corrupted and when using "chatr +dbg", the corruption is elsewhere.

Since 11.00 isn't supported, you are probably out of luck. Make sure you have the last set of patches.

[Laurent Menase]

main usual cause of that type of symptoms of heap corruption is buffer overflow which corrupt heap, causing it to give wrong
address ( zeroed of the leftmost valuable byte of the next address)

So check in your application you don't have any
string allocation which is forgetting to count ending 0.

typically
n=strlen(x);
s=malloc(n)
strncpy(s,x,n);

[Laurent Menase]

in my example it should be s=malloc(n+1);

[Jack Kidwell]

Thanks, Dennis and Laurent.

Since this code works fine on later versions of HPUX, and there are no mallocs used in the thread, I presume the unsupported B.11.00 is at fault. I'll use this information in my argument for moving off B.11.00.

[James R. Ferguson]

Hi Jack:

> I'll use this information in my argument for moving off B.11.00.

Aside from 11.0 having dropped out of support in December 2006, the new features and security enhancements of current supported releases should entice your management to migrate. You could at least run 11.11 on old K-class and D-class hardware if that's an issue :-)

Regards!

...JRF...

[Dennis Handly]

>there are no mallocs used in the thread

This statement doesn't mean it isn't heap corruption. There would have to be no mallocs in the whole process.

[Laurent Menase]

Yes in fact if one thread corrupts the heap, all threads of this process could fall on the corruption.


Typically some products like Rational "Purify"
Can help to find out that type of corruption.