topic Re: Problem in SHARE$PTHREAD in Operating System - OpenVMS

Problem in SHARE$PTHREAD

Strick213 — Fri, 03 Feb 2006 01:10:44 GMT

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

Re: Problem in SHARE$PTHREAD

Volker Halle — Fri, 03 Feb 2006 02:38:44 GMT

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.

Re: Problem in SHARE$PTHREAD

Strick213 — Fri, 03 Feb 2006 11:01:32 GMT

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

Re: Problem in SHARE$PTHREAD

Volker Halle — Fri, 03 Feb 2006 11:57:04 GMT

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.

Re: Problem in SHARE$PTHREAD

Jan van den Ende — Fri, 03 Feb 2006 11:57:24 GMT

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