Online Expert Day - HPE Data Storage - Live Now
April 24/25 - Online Expert Day - HPE Data Storage - Live Now
Read more
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Problem in SHARE$PTHREAD

Strick213
Occasional Visitor

Problem in SHARE$PTHREAD

We are having a problem with an extremely critical multi-threaded application crashing somewhere in the pthread RTL. The user code that it seems to be called from (rm_get_resp)is a simple loop looking for data in global memory. Here is the dump from the crash:

HRMU1B$ ana/process/image=exe:rmdriverz.exe rmdriverz.dmp

OpenVMS Alpha Debug64 Version V7.3-200


Some or all global symbols not accessible
Message number 004081A4
break on unhandled exception preceding SHARE$PTHREAD$RTL_DATA3+76392 in THREAD 3
Source lines not available for 0\%PC
Displaying source for 9\%PC
DBG> show calls
module name routine name line rel PC abs PC
SHARE$PTHREAD$RTL_DATA0 0000000000012A68 000000007BD26A68
SHARE$PTHREAD$RTL_DATA0 000000000003C3D8 000000007BD503D8
FFFFFFFF80156DA4 FFFFFFFF80156DA4
FFFFFFFF8026719C FFFFFFFF8026719C
SHARE$TRACE_DATA1 00000000000002CC 000000007B9A02CC
FFFFFFFF80268120 FFFFFFFF80268120
----- above condition handler called with exception 0000000C:
Access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000000000, PS=0000001B
----- end of exception message
FFFFFFFF8009C09C FFFFFFFF8009C09C
0000000000000000 0000000000000000
----- the above looks like a null frame in the same scope as the frame below
*RMIPCOMM rmipreads ? ?
*RMDRIVER rm_get_resp 44275 00000000000012CC 00000000000359FC
*RMDRIVER rm_io_r3 45650 000000000000412C 000000000003885C
*RMDRIVER workthread_r6
47868 000000000000AA60 000000000003F190
SHARE$PTHREAD$RTL_DATA0 0000000000025D7C 000000007BD39D7C
SHARE$PTHREAD$RTL_DATA0 0000000000012B90 000000007BD26B90
0000000000000000 0000000000000000
----- the above looks like a null frame in the same scope as the frame below
SHARE$PTHREAD$RTL_DATA0 ? ?
FFFFFFFF80267E94 FFFFFFFF80267E94
DBG>

Help?
TIA
4 REPLIES
Volker Halle
Honored Contributor

Re: Problem in SHARE$PTHREAD

Strick213,

the problem seems to start with an ACCVIO, trying to jump/call to a PC value of 0.

Try to follow the code flow from rm_get_resp line 44275 onwards. Consider to use SHOW STACK to locate the call frame to rmipreads and then look on the stack to try to find what's happening.

Volker.
Strick213
Occasional Visitor

Re: Problem in SHARE$PTHREAD

But - the access violation is in the PTHREAD library somewhere. How does one track down a problem like that?
Volker Halle
Honored Contributor

Re: Problem in SHARE$PTHREAD

Strick213,

the final problem may be in the PTHREAD$RTL library, but you can't solve that problem anyway without access to the PTHREAD source listings. Just concentrate on the first ACCVIO from above your rmipreads routine.

Try a DBG> SHOW STACK and locate the stack frame, which corresponds to the call from rm_get_resp line 44275 to rmipreads. You may need to switch to SDA and use SDA> SHOW CALL to more easily find the return PCs.

Volker.
Jan van den Ende
Honored Contributor

Re: Problem in SHARE$PTHREAD

Strick213,

Sorry, no answers from me on this one, Volker is the expert, but I noticed this is your first post:

WELCOME to the VMS forum!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.