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
|