SEGV_ACCERR - Invalid Permissions for object

[Agostinho Sousa]

We have a program in a 'HP-UX B.11.31 U ia64 2980234654 unlimited-user license' machine that uses Oracle Pro*C.
The program sometimes creates a core in the connection to the database (Oracle 10g - 10.2.0).
We examine the core with gbd and the backtrace tells:

...
Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
warning: Load module /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1 has been stripped.
Debugging information is not available.

warning: Load module /oracle/BSCS/product/10.2.0/lib/libnnz10.so has been stripped.
Debugging information is not available.

#0 0xc000000000492520:1 in __mxn_sleep ()
at /ux/core/libs/threadslibs/src/common/pthreads/sleep.c:1059
1059 /ux/core/libs/threadslibs/src/common/pthreads/sleep.c: No such file or directory.
in /ux/core/libs/threadslibs/src/common/pthreads/sleep.c
(gdb) bt
#0 0xc000000000492520:1 in __mxn_sleep ()
at /ux/core/libs/threadslibs/src/common/pthreads/sleep.c:1059
#1 0xc000000000410d90:0 in + 0x4b0 ()
at /ux/core/libs/threadslibs/src/common/pthreads/mutex.c:3853
#2 0xc0000000004162b0:0 in pthread_mutex_lock ()
at /ux/core/libs/threadslibs/src/common/pthreads/mutex.c:4210
#3 0xc00000000b7ad9e0:0 in sltsima+0x40 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#4 0xc00000000b30f2a0:0 in kpummpin+0x60 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#5 0xc00000000a38f930:0 in kpupin+0x90 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#6 0xc00000000a552b60:0 in OCIInitialize+0x40 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#7 0xc00000000a2b4680:0 in sqgctx+0x600 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#8 0xc00000000a2b3fa0:0 in sqgrct+0xa0 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#9 0xc00000000a2a7b70:0 in + 0xa20 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#10 0xc00000000a2a90d0:0 in sqlcxt+0x110 ()
from /oracle/BSCS/product/10.2.0/lib/libclntsh.so.10.1
#11 0x4000000000410080:0 in F_doCONNECT+0x1380 ()

Any clue from the above? Anyone having the same issue?
Thanks in advance.

[James R. Ferguson]

Hi:

Interestingly, there is a thread with the same subject as yours, just yesterday. See:

https://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1360995

Regards!

...JRF...

[Dennis Handly]

>Any clue from the above?

If you are getting a signal 11 in _mxn_sleep, it might be a thread stack overflow.
What version of gdb do you have?

Try these commands:
(gdb) bt
(gdb) frame 0
(gdb) disas $pc-16*8 $pc+16
(gdb) info reg

>JRF: there is a thread with the same subject as yours

Why would you think any two signal 11s are the same? You should at least match up a stack trace.

In this case it probably has something to do with thread. The other case is with a foreign devil C++ compiler and iostream.

[Agostinho Sousa]

first of all, thanks by the replies.

>What version of gdb do you have?

HP gdb 5.7 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.

The compiler is (from cc -V):
cc: HP C/aC++ B3910B A.06.15

>Try these commands:
>(gdb) bt
>(gdb) frame 0
>(gdb) disas $pc-16*8 $pc+16
>(gdb) info reg

typescript of the gdb session in attachment.

[Dennis Handly]

>HP gdb 5.7

You might want to download the latest, 6.0.

>typescript of the gdb session in attachment.

This stack trace is different from your original one, what changed?

This indicates you have a null pointer in r11.
Are you linking your application with -z so you abort sooner? (Your mutex address is NULL?)

Hmm, I guess this is libc's mutex for getpwuid_r.

Do you have the latest set of libc and libpthread patches?

[Agostinho Sousa]

>This stack trace is different from your original one, what changed?

Sorry, the attached stack trace was from a today core... in attachment the typescript from the original one.

>Are you linking your application with -z so you abort sooner? (Your mutex address is NULL?)
No, we are not.

>Do you have the latest set of libc and libpthread patches?
That we don't know (yet...). We do not admin the machine, it is our client production machine with their own unix admin team.

By the way, could it be a problem with the use of alarm()? We are using non local jumps to retry connection to database in case of slow connections and abort after 3 retries.
Also, we are linking with pthread but our program do not use threads (is just because we deliver an API to others that use threads).

Thanks for your reply.

[Dennis Handly]

>No, we are not.

This may help find where that NULL is occurring, sooner. Just use "chatr -z your-executable".

>could it be a problem with the use of alarm()?

Not sure how?

>We are using non local jumps to retry connection to database

You mean a setjmp/longjmp? If so, are you following the setjmp volatile rules?

>we are linking with pthread but our program do not use threads (is just because we deliver an API to others that use threads).

Just curious, if you don't link with libpthread and you don't use that API, can you measure the performance difference under some load?