Problem in SHARE$PTHREAD

[Strick213]

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

[Volker Halle]

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]

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

[Volker Halle]

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]

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