| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 2655.1 |  | TLE::REAGAN | All of this chaos makes perfect sense | Wed Jan 29 1997 09:13 | 17 | 
|  |     Where does this error come from?  Do you examine R0 in the
    debugger?  Some global variable, erno?  I don't see where
    the function "returns" an error.  What do you mean "at the
    last integer declared", is that from the traceback or
    SHOW CALLS output?  I'd like to see more information from your 
    debugging session.
    
    As for the XPO-W- error, how did you get the text?  EVAL/ERROR
    in the debugger?  I can safely say that the XPO-W error is
    meaningless.  I would guess that you are looking at a random
    value.  Look at the hex representation of the "error" and see
    if it doesn't look like data bytes.
    
    Do you compile with /CHECK?  Do you use /NOOPTIMIZE with /DEBUG?
    What platform and what version of the compiler?
    
    				-John
 | 
| 2655.2 | More info.... | VAXRIO::63198::csantos |  | Wed Jan 29 1997 12:28 | 57 | 
|  | 
	John,
	I do not know where this error comes from, all I know is that 
	after executing the function this error (always the same value)
	shows up at the last variable defined under VAR section.
                     How did I find that out, I did execute it with DEBUG and 	
	checked the values of the variables with EX, EX/HEX,
	EX/COND.
	I'll be posting the compile/link script at the end of this mail...
	Pascal version is V5.5 - AXP.
*****************************************************************************	
$rdml/pasc bp50o00
$pasc bp50o00 /noopt /align = vax/deb/USAGE=NOEMPTY /check
$rdml/pasc bp51o00
$pasc bp51o00 /noopt /align = vax  /deb/USAGE=NOEMPTY /check
$form translate bp50i1 
$form extract object bp50i1
$form translate bp50i2 
$form extract object bp50i2
$form translate bp50i3 
$form extract object bp50i3
$form translate bp50i4 
$form extract object bp50i4
$form translate bp50i5 
$form extract object bp50i5
$form translate bp51i1 
$form extract object bp51i1
$form translate bp51i2 
$form extract object bp51i2
$form translate bp51i3 
$form extract object bp51i3
$form translate bp52i1 
$form extract object bp52i1
$form translate bp53i1
$form extract object bp53i1
$linka:
$link bp50o00,bp50i1,bp50i2,bp50i3,bp50i4,bp50i5,bp51o00,-
bp51i1,bp51i2,bp52i1,bp53i1,[anarita.lixo]erros,uarpas,sys$library:rdm
lopt/opt/*
******************************************************************************
	What would you like to see from the debug???
				Thanks for helping
					Claudia
 | 
| 2655.3 |  | TLE::REAGAN | All of this chaos makes perfect sense | Wed Jan 29 1997 13:08 | 6 | 
|  |     If you don't know who is signalling the error, do a 
    SET BREAK /EXCEPTION in the debugger.  When the debugger stops
    at the exception, you can do a SHOW CALLS and see where it is
    coming from.  
    
    				-John
 | 
| 2655.4 | Strange... | VAXRIO::63198::csantos |  | Wed Jan 29 1997 13:56 | 16 | 
|  | 
	Bad news, set break/excep does not stop.  But the variable
	still comes with that value (teh error code), no matter 
	what I do.  One important thing is that customer said is
	that this program has been running for a long time, and
	it started returning the error after upgrading to Pascal
	5.5 (and recompiling/linking) the programs. 
	The problem is not the error itself, but the fact that it is 
	coming in a defined variable.  I know that it's strange...
		Thanks again
		
			Claudia
 | 
| 2655.5 |  | TLE::REAGAN | All of this chaos makes perfect sense | Wed Jan 29 1997 14:12 | 7 | 
|  |     Do a SET WATCH on the variable you are examining and see who
    writes into it.
    
    What compiler switches are you using?  What is the exact version
    number of the compiler (use ANAL/IMAGE to find it)?
    
    				-John
 | 
| 2655.6 |  | TLE::REAGAN | All of this chaos makes perfect sense | Wed Jan 29 1997 16:31 | 9 | 
|  |     Notice that if you treat 4 spaces as an error condition, you get:
    
    $ write sys$output f$message(%x20202020)
    %XPO-W-NOP1VA, P1 space not supported in shareable images
    
    It sure looks like you overwrote your "error" variable with blanks.
    Do you use /CHECK on the compilation?
    
    				-John
 | 
| 2655.7 |  | AUSS::GARSON | DECcharity Program Office | Wed Jan 29 1997 17:08 | 10 | 
|  |     re .0
    
    Assuming that the complaint is "integer_to_text returns a status of
    %X20202020 (as .6 points out)" ...
    
    Do we get to see how the caller declares "integer_to_text"?
    
    Do we get to see the source of "integer_to_text"?
    
    Do we get a complete but small reproducer program?
 | 
| 2655.8 | Debug output | VAXRIO::63198::csantos |  | Thu Jan 30 1997 07:54 | 96 | 
|  | 
	John,
	The compilation command is under .2.
	The version is: V5.5-51-3245
	Here is the debug output: 
*************************************************************************
$ RUN BP50O00
         OpenVMS Alpha AXP DEBUG Version V6.1-000
%DEBUG-I-INITIAL, language is PASCAL, module set to BP50O00
DBG> set break bp51z03_detalhe_colecao
DBG> set module bp51o00
DBG> go
...
break at routine BP51Z03_DETALHE_COLECAO
  3048: (*  527 *)   [Global]Procedure BP51Z03_DETALHE_COLECAO(
DBG> 
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3066
  3066: (*  545 *)      if g_numoc = 1 then
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3071
  3071: (*  550 *)        l_ctrlf := g_ctrlf;
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3074
  3074: (*  553 *)      CONt := 0;
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3076
  3076: (*  555 *)      G_INDICE := L_INDICE;
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3078
  3078: (*  557 *)      Y := g_indice;
DBG> SET WATCH Y/SOURCE/INTO
%DEBUG-E-NOSYMBOL, symbol 'SOURCE' is not in the symbol table
DBG> SET WATCH/INTO/SOURCE Y
%DEBUG-I-WPTTRACE, non-static watchpoint, tracing every instruction
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3080
  3080: (*  559 *)      While y <= G_max_lin   do
watch of BP51O00\BP51Z03_DETALHE_COLECAO\Y at 
BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3078
  3078: (*  557 *)      Y := g_indice;
   old value: 277276
   new value: 1
break at BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3080
  3080: (*  559 *)      While y <= G_max_lin   do
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3084
  3084: (*  563 *)        ind_chr := Integer_to_text(G_Indice,3);
DBG> S
watch of BP51O00\BP51Z03_DETALHE_COLECAO\Y at 
SHARE$LIBOTS_CODE0+3196
   old value: 1
   new value: 538976288
break at SHARE$LIBOTS_CODE0+3200
DBG> 
DBG> EX G_INDICE
BP51O00\G_INDICE:       1
DBG> S         
%DEBUG-I-DYNMODSET, setting module UARLIB
stepped to UARLIB\INTEGER_TO_TEXT\%LINE 56
    56: (*   54 *)   END;
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3084+48
  3084: (*  563 *)        ind_chr := Integer_to_text(G_Indice,3);
DBG> EX IND_CHR
BP51O00\BP51Z03_DETALHE_COLECAO\IND_CHR:        '..�'
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3088
  3088:            RDB$ERROR := FALSE;
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3088
DBG> S
stepped to BP51O00\BP51Z03_DETALHE_COLECAO\%LINE 3091
  3091:             IB_MSGVECTOR := ADDRESS (RDB$MESSAGE_VECTOR);
DBG> EX IND_CHR
BP51O00\BP51Z03_DETALHE_COLECAO\IND_CHR:        '  1'
DBG> EX/COND Y
BP51O00\BP51Z03_DETALHE_COLECAO\Y:      %XPO-W-NOP1VA, P1 
space not supported in shareable images
DBG> 
******************************************************************************
			Thanks once more
					Claudia
 | 
| 2655.9 |  | TLE::REAGAN | All of this chaos makes perfect sense | Thu Jan 30 1997 08:09 | 5 | 
|  |     I don't know why you think you are getting an error.  The
    convert_int_to_text seemed to work, right?  It string
    contains '  1'.  Is that the wrong answer?
    
    				-John
 | 
| 2655.10 | Y being modified - Why?? | VAXRIO::63198::csantos |  | Thu Jan 30 1997 08:22 | 6 | 
|  | 
	No, teh function is working correctly... The problem is 
	the variable Y that is being modified... Why???
			Claudia
 | 
| 2655.11 | Just a debugger oddity? | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Thu Jan 30 1997 08:46 | 8 | 
|  | What happens if you continue?  Does the program exit the loop prematurely?
It's possible that the debugger is just confused about where Y is stored,
and is showing you a memory location that isn't used for Y at the moment.
(It may have been used to hold Y at a different point in the program.)
If the program exits the loop prematurely, this looks like a bug, either
in the compiler or in something your program calls (such as Integer_to_text).
 | 
| 2655.12 | that's where it all started | VAXRIO::63198::csantos |  | Thu Jan 30 1997 10:35 | 15 | 
|  | 
	John,
	Yes, the program is getting an unexpected behavior
	even when we run it without the debug.  That's where
	everything started in the first place.
	I can not reproduce the problem with smaller program,
	so I guess is not a integer_to_text problem.  Would you
	like to post it's code here???
	
		Claudia
 | 
| 2655.13 | after upgrade | VAXRIO::63198::csantos |  | Thu Jan 30 1997 10:37 | 12 | 
|  | 
	John, 
	One more thing, maybe is a hint... It all started after 
	Pascal upgrade - and recompiling the code.
			
				Thanks again
					Claudia
 | 
| 2655.14 |  | TLE::REAGAN | All of this chaos makes perfect sense | Thu Jan 30 1997 13:47 | 14 | 
|  |     Yes, we need to see more code.  If it is large, email me the location
    of some source files along with a command file to build it, etc.
    to demonstrate the problem.
    
    Since the program gets different behavior after a compiler upgrade, it
    could be a compiler problem.  However, it may also be an uninitialized
    variable in your program.  The newer compiler may generate slightly
    different code, put variables in different registers, different
    stack locations, etc.  Uninitialized variables will then start with
    different "garbage" for their value which makes your program behave
    differently.
    
    				-John
    
 | 
| 2655.15 |  | TLE::REAGAN | All of this chaos makes perfect sense | Fri Feb 07 1997 11:22 | 14 | 
|  |     Just to close this out, it was a user error.  Upon access to the
    all the code, the INTEGER_TO_TEXT routine was declared in one
    module as returning a PACKED ARRAY [1..3] OF CHAR, but in the 
    module that declared the routine, it was returning a PACKED
    ARRAY [1..13] OF CHAR;  When the function wrote into the return
    location (ie, the hidden result buffer passed in by the calling
    routine), it overwrote the 10 bytes following the 3 character
    return value.
    
    I passed along this information to the customer.  If they would
    have used an environment file for these declarations, the compiler
    could have detected the type mismatch at compile-time.
    
    				-John
 |