|
HP OpenVMS Systemsask the wizard |
|
The Question is:
Compaq C++ V6.2-016 for OpenVMS Alpha V7.2-1 (pthread about the same version)
DS10
A multithreaded application does for some reason fail during the startup.
Currently it fails with ROPRAND at about the same number of instructions in
the code If instuctions are subtracted or added, it fails in a diffrent
location. Please see two exampl
es below.
Note after migrating from mixed CMA /pthread interface to a pure pthread
interface, some other pecularities occur. For instance, for a while it
crached with UNACVIO when translating logical names, but after changing
signed to unsigned variables, it were
OK.
I would assume that the code for some reason get corrupted at startup, but a
diff with the previous implementation does not reveal anything obvious.
%SYSTEM-F-ROPRAND, reserved operand fault at PC=00000000003A1630, PS=0000001B
break on unhandled exception at SHARE$PTHREAD$RTL+259632 in THREAD 1
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
Displaying source in a caller of the current routine
63044: pthread_delay_np( &delayxxx );
DBG> exit
%SYSTEM-F-ROPRAND, reserved operand fault at PC=00000000003A1630, PS=0000001B
break on unhandled exception at SHARE$PTHREAD$RTL+259632 in THREAD 1
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
Displaying source in a caller of the current routine
63043: qioTab[row].qioReady = FALSE;
DBG>
The Answer is : If the OpenVMS Wizard were going to guess, the guess would involve the plethora of potential programming problems posited in topic (1661). Finding the problem can involve use of the debugger or other techniques, moving forward through the application startup until the window where the corruption occurs is located, then narrowing the window. Various of the programming problems from topic (1661) might be located via a desk-check of the code. In addition to topic (1661), topic (6099) may also be of interest, as it covers threading and ASTs.
|