thread invokes library function, obtains "SEGV_MAPERR - Address not mapped to object"

[Svati Chandra]

I'm using HPUX v 11.31, ia64.
I'm running a simple test program that spawns threads to do
the same tasks, the task(function) defined in a user library.
The threads are created using POSIX thread API.

When a thread attempts to execute the library function,
the following error is generated:

Program received signal SIGSEGV, Segmentation fault
si_code: 1 - SEGV_MAPERR - Address not mapped to object.
0x9fffffffef61aac0:1 in TestJob (param=0x9fffffffef2f3d70)
at user_lib_private.c:2418
2418 ChannelHandle_t channelHandle = NULL;
(gdb) bt
#0 0x9fffffffef61aac0:1 in TestJob (param=0x9fffffffef2f3d70)
at user_lib_private.c:2418
#1 0x400000000000ba70:0 in testJobSubmission (pThreadMeta=0x60000000000245f0)
at tester.c:885
#2 0x4000000000009d40:0 in TesterThreadMain (
pThreadMetaAbstracted=0x60000000000245f0) at tester.c:649
#3 0x9fffffffef692d20:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1


Following a previous thread about a seemingly similiar issue,
I computed the current stack usage, and obtained the following:

(gdb) f 0
#0 0x9fffffffef61aac0:1 in uTestJob (param=0x9fffffffef2f3d70)
at user_lib_private.c:2418
2418 ChannelHandle_t channelHandle = NULL;
(gdb) p/x $save_sp=$sp
$8 = 0x9fffffffef293980
(gdb) frame 3
#3 0x9fffffffef692d20:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1
(gdb) p/x $sp - $save_sp
$9 = 0x69670
(gdb) p $sp - $save_sp
$10 = 431728


Suspecting a stack overflow situation, I increased the stack size
to a MB, but the issue still crops up.
The default stack size was found to be 256K using pthread API.

This probably eliminates the possibility of a stack overflow.
There seems to be an issue when the thread linking the shared library.
Why wouldnt why the address of a library function
be mapped/accessible in a thread's address space ?

Please suggest..

Thanks,
SC.


reg info attached herewith:

(gdb) info reg
pr0: 0x1
pr1: 0x1
pr2: 0
pr3: 0
pr4: 0
pr5: 0
pr6: 0x1
pr7: 0
pr8: 0x1
pr9: 0
pr10: 0
pr11: 0x1
pr12: 0
pr13: 0
pr14: 0
pr15: 0
pr16: 0
pr17: 0
pr18: 0
pr19: 0
pr20: 0
pr21: 0
pr22: 0
---Type to continue, or q to quit---
pr23: 0
pr24: 0
pr25: 0
pr26: 0
pr27: 0
pr28: 0
pr29: 0
pr30: 0
pr31: 0
pr32: 0
pr33: 0
pr34: 0
pr35: 0
pr36: 0
pr37: 0
pr38: 0
pr39: 0
pr40: 0
pr41: 0
pr42: 0
pr43: 0
pr44: 0
pr45: 0
---Type to continue, or q to quit---
pr46: 0
pr47: 0
pr48: 0
pr49: 0
pr50: 0
pr51: 0
pr52: 0
pr53: 0
pr54: 0
pr55: 0
pr56: 0
pr57: 0
pr58: 0
pr59: 0
pr60: 0
pr61: 0
pr62: 0
pr63: 0
gr0: 0
gr1: 0x9fffffffef7e8100
gr2: 0x400000000000bed0
gr3: 0
gr4: 0
---Type to continue, or q to quit---
gr5: 0
gr6: 0
gr7: 0
gr8: 0x9fffffffef74b9b0
gr9: 0x9fffffffef7f6730
gr10: 0x9fffffffef7abd70
gr11: 0x9fffffffef7abc10
gr12: 0x9fffffffef74b980
gr13: 0x6000000000026a80
gr14: 0
gr15: 0xc000000000000713
gr16: 0
gr17: 0x1f
gr18: 0
gr19: 0x9fffffffef7741a0
gr20: 0x9fffffffef7e2880
gr21: 0x9ffffffffffff360
gr22: 0x9fffffff7f7c8000
gr23: 0x2b
gr24: 0
gr25: 0x9ffffffffffff3b8
gr26: 0
gr27: 0x1
---Type to continue, or q to quit---
gr28: 0
gr29: 0
gr30: 0
gr31: 0x710
gr32: 0x9fffffffef7abd70
gr33: 0x9fffffffef7abd70
gr34: 0
gr35: 0
gr36: 0
gr37: 0x3b
gr38: 0
gr39: 0x288
gr40: 0x59
gr41: 0
gr42: 0x288
gr43: 0
gr44: 0
gr45: 0
gr46: 0
gr47: 0
gr48: 0
gr49: 0
gr50: 0
---Type to continue, or q to quit---
gr51: 0
gr52: 0
gr53: 0
gr54: 0x4b
gr55: 0x1
gr56: 0x710
gr57: 0
gr58: 0
gr59: 0
gr60: 0
gr61: 0
gr62: 0
gr63: 0
gr64: 0
gr65: 0
gr66: 0x9fffffffef7e8100
gr67: 0xc000000000000713
gr68: 0x400000000000bed0
gr69: 0x2
gr70: 0x710
gr71: 0
gr72: 0
gr73: 0
---Type to continue, or q to quit---
gr74: 0
gr75: 0
gr76: 0
br0: 0x400000000000bed0
br1: 0
br2: 0
br3: 0
br4: 0
br5: 0
br6: 0xc00000000737aa90
br7: 0xe00000010868c720
rsc: 0x1f
bsp: 0x9fffffffef774178
bspst: 0x9fffffffef774178
rnat: 0
ccv: 0
unat: 0
fpsr: 0x9804c8270433f
pfs: 0xc000000000000713
(sor:0, sol:14, sof:19)
lc: 0
ec: 0
ip: 0xc00000000737aac1
---Type to continue, or q to quit---
cfm: 0x12ad
(sor:0, sol:37, sof:45)
psr: 0

[Dennis Handly]

>Suspecting a stack overflow situation, I increased the stack size to a MB, but the issue still crops up. The default stack size was found to be 256K using pthread API.

The default stack size is 128 Kb for the user stack and 128 Kb for the RSE stack. You need to do the same exercise for your 1 Mb combined thread stack.

>Why wouldn't why the address of a library function be mapped/accessible in a thread's address space?

Why would you think you have a signal on the PC address, instead of on the data address? (You haven't proved there are zebras here yet. ;-)

>reg info attached herewith:

This is useless without the disassembly:
disas $pc-16*8 $pc+16*4

[Svati Chandra]

Thanks for your prompt response Dennis, appreciate it.
Here go:

(gdb) disas $pc-16*8 $pc+16*4
Dump of assembler code from 0xc0000000070faa40:0 to 0xc0000000070fab00:0:
;;; File: user_lib_private.c
;;; 2290 uWrn("Device %u reset failed: %s\n", deviceNum, uGetReturnCodeString(retval));
0xc0000000070faa40:0 : ld8 r1=[r32]
0xc0000000070faa40:1 : mov r42=r10
0xc0000000070faa40:2 : mov b6=r9
0xc0000000070faa50:0 : nop.m 0x0
0xc0000000070faa50:1 : nop.m 0x0
0xc0000000070faa50:2 : br.call.dptk.few b0=b6;;
0xc0000000070faa60:0 : mov r1=r38
0xc0000000070faa60:1 : nop.i 0x0
0xc0000000070faa60:2 : nop.i 0x0;;
;;; 2293 return retval;
0xc0000000070faa70:0 : mov r8=r36
0xc0000000070faa70:1 : mov b0=r40
0xc0000000070faa70:2 :
adds r12=16,r12;;
0xc0000000070faa80:0 : nop.m 0x0
0xc0000000070faa80:1 :
mov.i ar.pfs=r39
0xc0000000070faa80:2 : br.ret.dptk.few b0;;
;;; 2416 {
---Type to continue, or q to quit---
0xc0000000070faa90:0 :
alloc r67=ar.pfs,0,37,8,0
0xc0000000070faa90:1 : mov r10=0x603e0
0xc0000000070faa90:2 : mov r68=b0
0xc0000000070faaa0:0 : mov r66=r1;;
0xc0000000070faaa0:1 :
sub r12=r12,r10
0xc0000000070faaa0:2 :
mov r10=0x603e0;;
0xc0000000070faab0:0 :
add r10=r10,r12;;
0xc0000000070faab0:1 :
stf.spill [r10]=f16,16
0xc0000000070faab0:2 : mov r33=r32
;;; 2418 ChannelHandle_t channelHandle = NULL;
0xc0000000070faac0:0 :
adds r8=48,r12;;
0xc0000000070faac0:1 : st8 [r8]=r0
;;; 2419 unsigned long numSubmitted = 0, numCompleted = 0;
0xc0000000070faac0:2 : mov r35=0
0xc0000000070faad0:0 : mov r36=0
;;; 2421 double totalTime = 0;
0xc0000000070faad0:1 : mov f16=f0
---Type to continue, or q to quit---
;;; 2423 uint64_t numOutputErrors= 0;
0xc0000000070faad0:2 : mov r37=0;;
;;; 2424 uint64_t numOutputMetaErrors= 0;
0xc0000000070faae0:0 : mov r9=0
0xc0000000070faae0:1 :
0xc0000000070faae0:2 :
movl r8=0x60268;;
0xc0000000070faaf0:0 :
add r8=r8,r12;;
0xc0000000070faaf0:1 : st8 [r8]=r9
;;; 2425 uint64_t numStatusErrors= 0;
0xc0000000070faaf0:2 : mov r9=0
End of assembler dump.
(gdb) bt
#0 0xc0000000070faac0:1 in TestJob (param=0x9fffffffef7abd70)
at user_lib_private.c:2418
#1 0x400000000000bed0:0 in testJobSubmission (pThreadMeta=0x6000000000024610)
at tester.c:903
#2 0x400000000000a1a0:0 in TesterThreadMain (
pThreadMetaAbstracted=0x6000000000024610) at tester.c:667
#3 0xc0000000000ded20:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1

[Dennis Handly · Accepted solution]

You have a thread stack overflow:
0xc0000000070faa90:1 : mov r10=0x603e0
0xc0000000070faaa0:1 : sub r12=r12,r10

The size of your frame is 394,208 (0x603e0).

;; 2418 ChannelHandle_t channelHandle = NULL;
0xc0000000070faac0:0 : adds r8=48,r12;;
0xc0000000070faac0:1 : st8 [r8]=r0 << Signal here

You are storing NULL into the local channelHandle.

[Svati Chandra]

Thanks again Dennis.

The issue finally got narrowed down to allocating an array of 192K off the stack, down further in the library function.

I'm not sure yet why even after increasing the stacksize(i went upto 8MB), the issue recurred, but simply modifying the function to allocate the variable off the heap instead made things work.

I'd like to thank you again for your help in resolving this issue.

[Svati Chandra]

issue resolved, thanks..