I use GT.M for about 3 years now with no big problems.
But since i changed to a new Server running with Ubuntu 6.10 Server
i encounter sometimes strange Problems with Global-Entrys which are not found by the program.
The last thing i could reproduce several times is this:
Program Code:
-----------------------------
W !,$ZGBLDIR,!
S SATZ=$G(^SD010V(YM,ARTNR,EB))
W !!,"****",SATZ,!!
B
-----------------------------
Output:
-----------------------------
/daten/globals/mumps.gld
****;;;;;;;;;;;;;;;;;;;;;3.20
%GTM-I-BREAK, Break instruction encountered
At M source location POSEND+6^KTERM17
GTM>W $G(^SD010V(YM,ARTNR,EB))
;;;;;;;;;;;;;;;;;;;;;3.33
GTM>W $ZGBLDIR
/daten/globals/mumps.gld
-----------------------------
As you see the command direct from the command-line gives a different Value(correct) than then Program Output. The above entry with the 3.20 is not found in the entire Global (%GSE)
I have no clue why this happens.
I ll revert back to my Mandrake server.
BTW: I have Problems with both Versions, the old 4.4 I always used and the actual 5.2 but only on the new machine.
Greets
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I 've tested the same thing now with a copy of the database and a copy of programs and objects on the "old machine, which is running with mandrake and a 2.6.12.2 "Vanilla"-Kernel. The same routine works without problems here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found out more now: The Problem does not depend on the Linux Distribution, but on the environment-variable gtm_ztrap_form: when this variable is set to "adaptive" the Problem is a Problem, when set to "entryref" there's no Problem.
-------- maybe this helps one of the sanchez-gurus to find out whats going wrong here
Greets
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Below is a quote from the manual on the behavior of the intrinsic special variable $ZTRAP. Does this help?
Regards
-- Bhaskar
-----------------------------------------
There are four accepted behavioural forms of $ZTRAP controlled by the UNIX environment variable gtm_ztrap_form. If gtm_ztrap_form is defined to "code" (or not defined to one of the subsequently described values), then GT.M treats $ZTRAP as code and handles it as previously described in the documentation.
The four different behavioural forms of gtm_ztrap_form are:
+ entryref - If gtm_ztrap_form evaluates to "entryref" then GT.M treats it as an entryref argument to an implicit GOTO command.
+ adaptive - If gtm_ztrap_form evaluates to "adaptive" then if $ZTRAP does not compile to valid M code, then $ZTRAP is treated as just described for "entryref." Since there is little ambiguity, code and entryref forms of $ZTRAP can be intermixed in the same application.
* Note that GT.M attempts to compile $ZTRAP before evaluating $ZTRAP as an entryref. Since GT.M allows commands without arguments such as QUIT, ZGOTO, or HANG as valid labels, be careful not to use such keywords as labels for error handling code in "adaptive" mode.
+ pope[ntryref] / popa[daptive] - If gtm_ztrap_form evaluates to "POPE[NTRYREF]" or "POPA[DAPTIVE]" (case insensitive) and $ZTRAP value is in the form of entryref, GT.M unwinds the M stack from the level at which an error occurred to (but not including) the level at which $ZTRAP was last SET. Then, GT.M transfers control to the entryref in $ZTRAP at the level where the $ZTRAP value was SET. If the UNIX environment variable gtm_zyerror is defined to a valid entryref, GT.M transfers control to the entryref specified by GTM_ZYERROR (with an implicit DO) after unwinding the stack and before transferring control to the entyref specified in $ZTRAP.
-----------------------------------------
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi bhaskar,
thank you for your answer. I think i got what gtm_ztrap does, but with the "adaptive"-setting i encountered some severe Problems. In some cases $DATA of a Global was false even when the Global was defenitly defined. And i had another problem i reproduced again and again:
The last thing i could reproduce several times is this:
Program Code:
-----------------------------
W !,$ZGBLDIR,!
S SATZ=$G(^SD010V(YM,ARTNR,EB))
W !!,"****",SATZ,!!
B
-----------------------------
Output:
-----------------------------
/daten/globals/mumps.gld
****;;;;;;;;;;;;;;;;;;;;;3.20
%GTM-I-BREAK, Break instruction encountered
At M source location POSEND+6^KTERM17
As you see i get different values out of the same global-node. I did the same steps again with gtm_ztrap changed to "entryref" and everything works fine. Changed back to "adaptive" the problem came back.(But the database-integrity-check was ok all the time)
It's been 6 weeks ago now and i had no more problems since the change of the setting.
So i guess there must be some side-effects which affect Global-access in rare cases.
I'd like to help finding that bug but my knowledge of "C++" is really poor.
Greets
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In order to help in understanding this issue, could you provide more context - a reproducible case if you can construct one, otherwise ZSHOW "*" at the time of the failure and the code in the failing routine.
Thanks,
Roger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The error is not to reproduce easily, i tried my best:
Here are two times output of ZSHOW "*" I just eliminated some uninteresting local variables.
With the first run of the code global BA030 is found, in the 2nd run GT.M it is not found.
Back on the command-line i can access the global again. I tried to insert the line
"S %MERK=$D(^BA030(YM,"AUT",1))" before the $DATA-line but then the error does not come up.
Looks like a little Problem when the system once entered error-handling.
Sorry i can't describe better and my english doesn't help much also.
EING(XPOS,YPOS,L,VG) ;XPOS,YPOS=EINGABEPOSITION,L=MAX-LAENGE,VG=VORGABESTRING
EGEIN NEW X,RG,MX,A,L1,M1,B,VT,T,EX,MZT
EGEI3 ;S X=.0 X YEP W $REFERENCE,"****"
;S X=.1 X YEP W $ZT,"****"
;S X=XPOS_"."_YPOS,RG=VG,MX=$L(VG),EX=0 D ANZ U 0:NOECHO
;U 0:NOCENABLE
O "/daten/testerr":APPEND U "/daten/testerr" ZSHOW "*" W !,"--------------------------------",! C "/daten/testerr"
I '$D(^BA030(YM,"AUT",1)) B
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you using external calls? I ask because the behavior you describe is similar to what we've seen when an external call updates information outside its legitimate arguments (GT.M does not check for such things because of the performance implications).
Am I correct in understanding that the two test "results" are identical except for a differing line width causing additional lines in the second case of the ZSHOW "*" output?
Am I correct in guessing that the code fragment shows the problem global reference, but is not the actual failing code? Would it be possible to see the actual failing [sub-]routine and also actual values of the subscripts in the ZSHOW "* output?
Thanks,
Roger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now i've figured out a small test-example which hopefully helps tracking down the problem:
i ve created a routine named KTEST94.m like this:
ST ;Test
K ^XTEST
S $ZT="ERR^"_$T(+0),VAR="SCHNULLI",YM=0
D set^%GBLDEF("^XTEST",1,0)
S ^XTEST(YM)="Test"
W $D(^XTEST(YM))
D TEST2
Q
TEST2 W $D(^XTEST(YM))
D @VAR
Q
ERR W $D(^XTEST(YM))
Q
--------------------------------------------------------------
With gtm_ztrap_form=adaptive it looks like this:
GTM>D ^KTEST94
0110
GTM>D ^KTEST94
0111
With gtm_ztrap_form=entryref it looks like this:
GTM>d ^KTEST94
0111
GTM>d ^KTEST94
0111
Does this help ?
Greets
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your fine example does the trick - we can see the problem and suspect that it's an errant memory reference (it seems very context sensitive). We'll have to prioritize a fix (contact Bhaskar if you want to make a plea).
The workarounds are to use the standard $ETRAP mechanism or (as you've already found) avoid adaptive.
Thanks,
Roger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use GT.M for about 3 years now with no big problems.
But since i changed to a new Server running with Ubuntu 6.10 Server
i encounter sometimes strange Problems with Global-Entrys which are not found by the program.
The last thing i could reproduce several times is this:
Program Code:
-----------------------------
W !,$ZGBLDIR,!
S SATZ=$G(^SD010V(YM,ARTNR,EB))
W !!,"****",SATZ,!!
B
-----------------------------
Output:
-----------------------------
/daten/globals/mumps.gld
****;;;;;;;;;;;;;;;;;;;;;3.20
%GTM-I-BREAK, Break instruction encountered
At M source location POSEND+6^KTERM17
GTM>W $G(^SD010V(YM,ARTNR,EB))
;;;;;;;;;;;;;;;;;;;;;3.33
GTM>W $ZGBLDIR
/daten/globals/mumps.gld
-----------------------------
As you see the command direct from the command-line gives a different Value(correct) than then Program Output. The above entry with the 3.20 is not found in the entire Global (%GSE)
I have no clue why this happens.
I ll revert back to my Mandrake server.
BTW: I have Problems with both Versions, the old 4.4 I always used and the actual 5.2 but only on the new machine.
Greets
Jens
I 've tested the same thing now with a copy of the database and a copy of programs and objects on the "old machine, which is running with mandrake and a 2.6.12.2 "Vanilla"-Kernel. The same routine works without problems here.
I found out more now: The Problem does not depend on the Linux Distribution, but on the environment-variable gtm_ztrap_form: when this variable is set to "adaptive" the Problem is a Problem, when set to "entryref" there's no Problem.
-------- maybe this helps one of the sanchez-gurus to find out whats going wrong here
Greets
Jens
Jens --
Below is a quote from the manual on the behavior of the intrinsic special variable $ZTRAP. Does this help?
Regards
-- Bhaskar
-----------------------------------------
There are four accepted behavioural forms of $ZTRAP controlled by the UNIX environment variable gtm_ztrap_form. If gtm_ztrap_form is defined to "code" (or not defined to one of the subsequently described values), then GT.M treats $ZTRAP as code and handles it as previously described in the documentation.
The four different behavioural forms of gtm_ztrap_form are:
+ entryref - If gtm_ztrap_form evaluates to "entryref" then GT.M treats it as an entryref argument to an implicit GOTO command.
+ adaptive - If gtm_ztrap_form evaluates to "adaptive" then if $ZTRAP does not compile to valid M code, then $ZTRAP is treated as just described for "entryref." Since there is little ambiguity, code and entryref forms of $ZTRAP can be intermixed in the same application.
* Note that GT.M attempts to compile $ZTRAP before evaluating $ZTRAP as an entryref. Since GT.M allows commands without arguments such as QUIT, ZGOTO, or HANG as valid labels, be careful not to use such keywords as labels for error handling code in "adaptive" mode.
+ pope[ntryref] / popa[daptive] - If gtm_ztrap_form evaluates to "POPE[NTRYREF]" or "POPA[DAPTIVE]" (case insensitive) and $ZTRAP value is in the form of entryref, GT.M unwinds the M stack from the level at which an error occurred to (but not including) the level at which $ZTRAP was last SET. Then, GT.M transfers control to the entryref in $ZTRAP at the level where the $ZTRAP value was SET. If the UNIX environment variable gtm_zyerror is defined to a valid entryref, GT.M transfers control to the entryref specified by GTM_ZYERROR (with an implicit DO) after unwinding the stack and before transferring control to the entyref specified in $ZTRAP.
-----------------------------------------
Hi bhaskar,
thank you for your answer. I think i got what gtm_ztrap does, but with the "adaptive"-setting i encountered some severe Problems. In some cases $DATA of a Global was false even when the Global was defenitly defined. And i had another problem i reproduced again and again:
The last thing i could reproduce several times is this:
Program Code:
-----------------------------
W !,$ZGBLDIR,!
S SATZ=$G(^SD010V(YM,ARTNR,EB))
W !!,"****",SATZ,!!
B
-----------------------------
Output:
-----------------------------
/daten/globals/mumps.gld
****;;;;;;;;;;;;;;;;;;;;;3.20
%GTM-I-BREAK, Break instruction encountered
At M source location POSEND+6^KTERM17
GTM>W $G(^SD010V(YM,ARTNR,EB))
;;;;;;;;;;;;;;;;;;;;;3.33
GTM>W $ZGBLDIR
/daten/globals/mumps.gld
As you see i get different values out of the same global-node. I did the same steps again with gtm_ztrap changed to "entryref" and everything works fine. Changed back to "adaptive" the problem came back.(But the database-integrity-check was ok all the time)
It's been 6 weeks ago now and i had no more problems since the change of the setting.
So i guess there must be some side-effects which affect Global-access in rare cases.
I'd like to help finding that bug but my knowledge of "C++" is really poor.
Greets
Jens
Jens:
In order to help in understanding this issue, could you provide more context - a reproducible case if you can construct one, otherwise ZSHOW "*" at the time of the failure and the code in the failing routine.
Thanks,
Roger
The error is not to reproduce easily, i tried my best:
Here are two times output of ZSHOW "*" I just eliminated some uninteresting local variables.
With the first run of the code global BA030 is found, in the 2nd run GT.M it is not found.
Back on the command-line i can access the global again. I tried to insert the line
"S %MERK=$D(^BA030(YM,"AUT",1))" before the $DATA-line but then the error does not come up.
Looks like a little Problem when the system once entered error-handling.
Sorry i can't describe better and my english doesn't help much also.
Greets Jens
---------------------------------------------
$DEVICE=""
$ECODE=",Z2,M13,Z150373194,M13,Z150373194,"
$ESTACK=6
$ETRAP=""
$HOROLOG="60764,72090"
$IO="/daten/testerr"
$JOB=13417
$KEY=""
$PRINCIPAL="/dev/pts/2"
$QUIT=1
$REFERENCE="^DAV(""SD010"",""2"",""0222"")"
$STACK=6
$STORAGE=2147483647
$SYSTEM="47,gtm_sysid"
$TEST=0
$TLEVEL=0
$TRESTART=0
$X=0
$Y=18
$ZA=0
$ZALLOCSTOR=1030276
$ZB=""
$ZCHSET="M"
$ZCMDLINE=""
$ZCOMPILE=""
$ZCSTATUS=0
$ZDATEFORM=0
$ZDIRECTORY="/home/aut/"
$ZEDITOR=0
$ZEOF=1
$ZERROR="%GTM-E-LABELMISSING, Label referenced but not defined: ZP0222"
$ZGBLDIR="/daten/globals/mumps.gld"
$ZININTERRUPT=0
$ZINTERRUPT="new tmp set tmp=$H zshow ""*"":^|""/daten/globals/mumps.gld""|%job($J,tmp)"
$ZIO="/daten/testerr"
$ZJOB=0
$ZLEVEL=7
$ZMAXTPTIME=0
$ZMODE="INTERACTIVE"
$ZPATNUMERIC="M"
$ZPOSITION="EGEI3+2^KAUPZX"
$ZPROCESS=""
$ZPROMPT="GTM>"
$ZREALSTOR=1061208
$ZROUTINES="/daten/objects(/daten/routines /daten/kroutines /daten/groutines /daten/nroutines)"
$ZSOURCE=""
$ZSTATUS="150373194,ZUSPR+3^KTERM15,%GTM-E-LABELMISSING, Label referenced but not defined: ZP0222"
$ZSTEP="B"
$ZSYSTEM=0
$ZTEXIT=""
$ZTRAP="NOLAB^KTERM16"
$ZUSEDSTOR=1030276
$ZVERSION="GT.M V5.2-000A Linux x86"
$ZYERROR="PROCZY^BAUP02"
YM=0
/daten/routines/KTERM15.m CLOSED
/daten/testerr OPEN RMS
/dev/pts/2 OPEN TERMINAL CTRA=$C(3) NOPAST NOREADS TYPE WIDTH=255 LENG=0 EDIT
EGEI3+2^KAUPZX
INP+3^KTERM17
POSIT+14^KTERM17
ARTIK2+8^KTERM17
ARTIK2+7^KTERM17
HS^KTERM15
RESTART+2^BAVT01
--------------------------------
$DEVICE=""
$ECODE=",Z2,M13,Z150373194,M13,Z150373194,M13,Z150373194,"
$ESTACK=6
$ETRAP=""
$HOROLOG="60764,72092"
$IO="/daten/testerr"
$JOB=13417
$KEY=""
$PRINCIPAL="/dev/pts/2"
$QUIT=1
$REFERENCE="^BA030(""0"",""AUT"",""1"")"
$STACK=6
$STORAGE=2147483647
$SYSTEM="47,gtm_sysid"
$TEST=1
$TLEVEL=0
$TRESTART=0
$X=0
$Y=18
$ZA=0
$ZALLOCSTOR=1030276
$ZB=""
$ZCHSET="M"
$ZCMDLINE=""
$ZCOMPILE=""
$ZCSTATUS=0
$ZDATEFORM=0
$ZDIRECTORY="/home/aut/"
$ZEDITOR=0
$ZEOF=1
$ZERROR="%GTM-E-LABELMISSING, Label referenced but not defined: ZP0222"
$ZGBLDIR="/daten/globals/mumps.gld"
$ZININTERRUPT=0
$ZINTERRUPT="new tmp set tmp=$H zshow ""*"":^|""/daten/globals/mumps.gld""|%job($J,tmp)"
$ZIO="/daten/testerr"
$ZJOB=0
$ZLEVEL=7
$ZMAXTPTIME=0
$ZMODE="INTERACTIVE"
$ZPATNUMERIC="M"
$ZPOSITION="EGEI3+2^KAUPZX"
$ZPROCESS=""
$ZPROMPT="GTM>"
$ZREALSTOR=1061208
$ZROUTINES="/daten/objects(/daten/routines /daten/kroutines /daten/groutines /daten/nroutines)"
$ZSOURCE=""
$ZSTATUS="150373194,ZUSPR+3^KTERM15,%GTM-E-LABELMISSING, Label referenced but not defined: ZP0222"
$ZSTEP="B"
$ZSYSTEM=0
$ZTEXIT=""
$ZTRAP="NOLAB^KTERM16"
$ZUSEDSTOR=1030276
$ZVERSION="GT.M V5.2-000A Linux x86"
$ZYERROR="PROCZY^BAUP02"
YM=0
/daten/routines/KTERM15.m CLOSED
/daten/testerr OPEN RMS
/dev/pts/2 OPEN TERMINAL CTRA=$C(3) NOPAST NOREADS TYPE WIDTH=255 LENG=0 EDIT
EGEI3+2^KAUPZX
POSOK+2^KTERM17
POSIT+14^KTERM17
ARTIK2+8^KTERM17
ARTIK2+7^KTERM17
HS^KTERM15
RESTART+2^BAVT01
--------------------------------
Code:
EING(XPOS,YPOS,L,VG) ;XPOS,YPOS=EINGABEPOSITION,L=MAX-LAENGE,VG=VORGABESTRING
EGEIN NEW X,RG,MX,A,L1,M1,B,VT,T,EX,MZT
EGEI3 ;S X=.0 X YEP W $REFERENCE,"****"
;S X=.1 X YEP W $ZT,"****"
;S X=XPOS_"."_YPOS,RG=VG,MX=$L(VG),EX=0 D ANZ U 0:NOECHO
;U 0:NOCENABLE
O "/daten/testerr":APPEND U "/daten/testerr" ZSHOW "*" W !,"--------------------------------",! C "/daten/testerr"
I '$D(^BA030(YM,"AUT",1)) B
Jens:
Are you using external calls? I ask because the behavior you describe is similar to what we've seen when an external call updates information outside its legitimate arguments (GT.M does not check for such things because of the performance implications).
Am I correct in understanding that the two test "results" are identical except for a differing line width causing additional lines in the second case of the ZSHOW "*" output?
Am I correct in guessing that the code fragment shows the problem global reference, but is not the actual failing code? Would it be possible to see the actual failing [sub-]routine and also actual values of the subscripts in the ZSHOW "* output?
Thanks,
Roger
Now i've figured out a small test-example which hopefully helps tracking down the problem:
i ve created a routine named KTEST94.m like this:
ST ;Test
K ^XTEST
S $ZT="ERR^"_$T(+0),VAR="SCHNULLI",YM=0
D set^%GBLDEF("^XTEST",1,0)
S ^XTEST(YM)="Test"
W $D(^XTEST(YM))
D TEST2
Q
TEST2 W $D(^XTEST(YM))
D @VAR
Q
ERR W $D(^XTEST(YM))
Q
--------------------------------------------------------------
With gtm_ztrap_form=adaptive it looks like this:
GTM>D ^KTEST94
0110
GTM>D ^KTEST94
0111
With gtm_ztrap_form=entryref it looks like this:
GTM>d ^KTEST94
0111
GTM>d ^KTEST94
0111
Does this help ?
Greets
Jens
Jens:
Your fine example does the trick - we can see the problem and suspect that it's an errant memory reference (it seems very context sensitive). We'll have to prioritize a fix (contact Bhaskar if you want to make a plea).
The workarounds are to use the standard $ETRAP mechanism or (as you've already found) avoid adaptive.
Thanks,
Roger