[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::pascal

Title:DEC Pascal Notes
Notice:See note 1 for kits. Bug reports to CLT::DEC_PASCAL_BUGS
Moderator:TLE::REAGAN
Created:Sat Jan 25 1986
Last Modified:Tue Jun 03 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2675
Total number of notes:13409

2655.0. "FUNCTION RETURNING ERROR ON THE LAST DECLARED VARIABLE" by VAXRIO::63198::csantos () Wed Jan 29 1997 10:35


	Hi,

	I'm not a Pascal expert, so please forgive me if I'm asking
	something obvious.

	We have a customer running a program that calls a funtion.
	The function is returning an error, but not at the returning
	variable, always at the last integer declared.
	I'll show next:

***************************************************************************

	The procedure

***************************************************************************
[Global]Procedure BP51Z03_DETALHE_COLECAO(
                                 Var Reg_colecao : p8;
                                 Var l_ctrlf : integer; 
                                     l_indice : integer;
                                 Var l_cont_tit : integer;
                                 Var l_vetor : integer;
                                 Var L_l     : integer;
                                 Var l_ntit : integer;
                                 Var l_tottit : integer);

Var

   Ind_chr       : Packed Array[1..3] of char;
   kcont_int     : integer;
   cont,y        : integer;

Begin 
   
   if g_numoc = 1 then
     l_ctrlf := g_max_lin
   else
     l_ctrlf := g_ctrlf;

   CONt := 0;     
   G_INDICE := L_INDICE;
   Y:= g_indice;

   While y <= G_max_lin   do

   BEGIN

    ind_chr := Integer_to_text(G_Indice,3);  ******** ERROR  ***********
    For v in Vbpe23 with v.CTIT = g_cod_titulo AND V.KCONT =IND_CHR
         on error 
            begin
             tratamento_erros(erro);
             writeln('Erro = ',erro,' na pesquisa da Vbpe23 -Procedure 
BP51Z03*
            end;
         end_error;

         if ((G_Indice <= G_Max_Lin) and (G_indice <= (G_l * NLIN)))  then
                     begin
                        kcont_int := Text_to_Integer(v.kcont);
                        CONT:= CONT + 1;
                        Reg_colecao[CONT].tcolecao := v.mcole;
                        G_indice := G_indice + 1;
                        ind_chr := Integer_to_text(G_Indice,3);
                        y:= y + 1;
                end
                else
                        y:= g_max_lin + 1;

     End_for;
   END; 

l_indice   := g_indice;
l_cont_tit := g_cont_tit;
l_l        := g_l;
l_vetor    := g_vetor[g_l];
l_ntit     := g_ntit;
l_tottit   := g_tottit;

end;

***************************************************************************


	When we run this with decug we see that after the execution
   of the function INTEGER_TO_TEXT an error is returned on the last 
   variable defined - that case Y.  

	The error is : 

        %XPO-W-NOP1VA, P1 space not supported in shareable images

	If we declare any other variable after that it will be returned
    on the new one declared.


	Why is this error being returned in the last variable??



			Thaks for helping 

				Claudia
T.RTitleUserPersonal
Name		DateLines
2655.1TLE::REAGANAll of this chaos makes perfect senseWed Jan 29 1997 12:1317
    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.2More info....VAXRIO::63198::csantosWed Jan 29 1997 15:2857

	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.3TLE::REAGANAll of this chaos makes perfect senseWed Jan 29 1997 16:086
    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.4Strange...VAXRIO::63198::csantosWed Jan 29 1997 16:5616

	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.5TLE::REAGANAll of this chaos makes perfect senseWed Jan 29 1997 17:127
    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.6TLE::REAGANAll of this chaos makes perfect senseWed Jan 29 1997 19:319
    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.7AUSS::GARSONDECcharity Program OfficeWed Jan 29 1997 20:0810
    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.8Debug outputVAXRIO::63198::csantosThu Jan 30 1997 10:5496
2655.9TLE::REAGANAll of this chaos makes perfect senseThu Jan 30 1997 11:095
    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.10Y being modified - Why??VAXRIO::63198::csantosThu Jan 30 1997 11:226

	No, teh function is working correctly... The problem is 
	the variable Y that is being modified... Why???

			Claudia
2655.11Just a debugger oddity?WIBBIN::NOYCEPulling weeds, pickin' stonesThu Jan 30 1997 11:468
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.12that's where it all startedVAXRIO::63198::csantosThu Jan 30 1997 13:3515

	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.13after upgradeVAXRIO::63198::csantosThu Jan 30 1997 13:3712

	John, 


	One more thing, maybe is a hint... It all started after 
	Pascal upgrade - and recompiling the code.

			
				Thanks again

					Claudia
2655.14TLE::REAGANAll of this chaos makes perfect senseThu Jan 30 1997 16:4714
    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.15TLE::REAGANAll of this chaos makes perfect senseFri Feb 07 1997 14:2214
    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