[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEBUG |
| Notice: | Updated locations for reporting QARs -- see note 834.1 |
| Moderator: | LOWFAT::DIETER |
|
| Created: | Fri Jan 24 1986 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1868 |
| Total number of notes: | 8200 |
1836.0. "Formatted WRITE (Fortran) ACCVIOs in /DEBUG" by CSC32::HENNING (A rose with no thorns) Fri Feb 07 1997 16:30
Compiler: DFAV V6.3-711-293V
RTL: FORRTL V01-05.297 (from FORRTLAVE01070)
ECOs: ALPACRT09_061, ALPDEBU06_070 and ALPLIBR04_070
Appreciate your input/comment on the following, and will cross-post to
FORTRAN conference:
A customer reports that a Fortran program that is compiled and linked
/DEBUG ACCVIOs at execution of a formatted I/O statement.
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=A05E7904, PC=A05E7904, PS=0000001B
The program fails with an ACCVIO from RUN/DEBUG or RUN/NODEBUG. If the
image is linked /NODEBUG, the program executes without error. I've
attached customer's commands and output to the end of this message.
I've been unable to reproduce the behavior, using the same compiler and
RTL. The ACCVIO persists after installing the most recent versions of
the ECO kits ALPACRT09_061, ALPDEBU06_070 and ALPLIBR04_070, and
rebooting the system.
Checksums of the following images (in process space at the ACCVIO) were
consistent with expected checksum values for the images:
CMA$TIS_SHR DPML$SHR
DBGTBKMSG LIBOTS
DEBUG LIBRTL
DEC$FORRTL SHRIMGMSG
DECC$MSG SYS$SSISHR
DECC$SHR
Are there any suggestions as to what to check? Are there any reports
with similar symptoms in DBGBUGS (no access to that conference)?
Thanks in advance,
Mary
=============================================
The following demonstrates the failure:
$ TYPE HELLO.FOR
type *,'Hello'
write (6,100) 'Hello'
100 format (x,a)
call exit
end
$ FORT HELLO
$ LINK HELLO
$ RUN HELLO
Hello
Hello
$ FORT/DEB/NOOPT HELLO
$ LINK/DEB HELLO
$ SHOW LOG/FULL D*B*G
(LNM$PROCESS_TABLE) [kernel]
[no protection information]
(LNM$JOB_80B4DC80) [kernel] [shareable] [Quota=(3664,4096)]
[Protection=(RWCD,RWCD,,)] [Owner=[GHC]]
(LNM$GROUP_000211) [kernel] [shareable,group]
[Protection=(RWCD,R,R,)] [Owner=[211,*]]
(LNM$SYSTEM_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]
"DBG$INPUT" [super] = "SYS$INPUT:"
"DBG$OUTPUT" [super] = "SYS$OUTPUT:"
"DBLMSGMGR" [exec] = "DBLMSGMGR_TV"
"DBLRTLMSG" [exec] = "DBL$MSG"
$ RUN HELLO
OpenVMS Alpha AXP DEBUG Version V6.1-05R
%DEBUG-I-INITIAL, language is FORTRAN, module set to H$MAIN
DBG> go
Hello
%DEBUG-W-SCRNOSRCLIN, no source line for address A05E7904 for display
in Source View
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=A05E7904, PC=A05E7904, PS=0000001B
break on unhandled exception at 2690545924
$ RUN/NODEBUG HELLO
Hello
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=A05E7904, PC=A05E7904, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
Image Name Module Name Routine Name Line Number rel PC abs PC
0 A05E7904 A05E7904
0 805EA224 805EA224
DEC$FORRTL 0 0007960C 000BB60C
DEC$FORRTL 0 00074D5C 000B6D5C
DEC$FORRTL 0 0004E5E4 000905E4
DEC$FORRTL 0 00085150 000C7150
HELLO HELLO$MAIN HELLO$MAIN 4 00000098 00030098
0 830B7D90 830B7D90
NOTE: after installing the ECO kits, the customer tested the image
again -- which ACCVIO'd again, but with a slightly different VA/PA.
Here's the ACCVIO and the list of images:
DBG> GO
Hello
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=A05E7EE4, PC=A05E7EE4, PS=0000001B
break on unhandled exception at 2690547428
DBG> show image
image name set base address end address
CMA$TIS_SHR no 002A6000 002AA1FF
CODE0 8049A000 8049ABFF
DATA1 002A6000 002A69FF
DATA2 002A8000 002A81FF
DATA3 002AA000 002AA1FF
DBGTBKMSG no 004DC000 004E8BFF
DEBUG no 003C0000 004D09FF
DEC$FORRTL no 00042000 00112BFF
DECC$MSG no 004D2000 004D33FF
DECC$SHR no 0011C000 0023D9FF
CODE0 80562000 8061E9FF
DPML$SHR no 0023E000 002A4FFF
CODE0 8049C000 805611FF
DATA1 0023E000 002745FF
DATA2 00276000 0028B5FF
DATA3 0028C000 0028C3FF
DATA4 0028E000 002A81FF
DATA5 002A4000 002A4FFF
*HELLO yes 00010000 000401FF
LIBOTS no 00114000 0011A1FF
CODE0 8048C000 80499BFF
DATA1 00114000 001165FF
DATA2 00118000 00119BFF
DATA3 0011A000 0011A1FF
LIBRTL no 002AC000 0038D3FF
CODE0 80400000 8048B5FF
SHRIMGMSG no 004D4000 004DA9FF
SYS$SSISHR no 0038E000 003BE3FF
total images: 12 bytes allocated: 116016
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1836.1 | fortran | SSPADE::SSPADE::HILDE | | Mon Feb 10 1997 11:13 | 9 |
|
The key here to getting the debugger off the hook ;-) is the ACCVIO when
RUN/NODEBUG. In that case, there is no debugger present/activated...so it
can't possibly be involved. I'm curious, however, as to what happens if
they compile /NODEBUG/NOOPT...(I also am unable to reproduce the problem).
Note also that the ACCVIO traceback points the finger at DEC$FORRTL.
Lon
|
| 1836.2 | | CSC32::HENNING | A rose with no thorns | Mon Feb 10 1997 12:33 | 28 |
| > The key here to getting the debugger off the hook ;-) is the ACCVIO
> when RUN/NODEBUG. In that case, there is no debugger present/activated
> ...so it can't possibly be involved.
;^) back atcha!
True, though the ACCVIO only occurs if the image is compiled and
linked /DEBUG.
> I'm curious, however, as to what happens if they compile /NODEBUG/NOOPT
I'll check on that.
> Note also that the ACCVIO traceback points the finger at DEC$FORRTL.
True. Am working that in the Fortran notes conference.
BTW, the customer indicates that he isn't running DECps (V2.1 had a sw
problem that zeroed out the upper 32bits of Alpha registers), and that
the problem occurs even without the format:
WRITE (6,*) 'Hello'
Thanks, Lon!
Mary
|
| 1836.3 | | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Mon Feb 10 1997 16:02 | 28 |
| > Note also that the ACCVIO traceback points the finger at DEC$FORRTL.
I don't think so.
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> Image Name Module Name Routine Name Line Number rel PC abs PC
> 0 A05E7904 A05E7904
> 0 805EA224 805EA224
> DEC$FORRTL 0 0007960C 000BB60C
> :
> DBG> show image
> image name set base address end address
> :
> DECC$SHR no 0011C000 0023D9FF
> CODE0 80562000 8061E9FF
> :
It looks to me as if DEC$FORRTL called into DECC$SHR which then (at 805EA224)
took a wild branch. It's not clear whether the Fortran RTL, the C RTL, or something
else is to blame.
Something in this customer's environment is unusual. I would tend to suspect
the memory-resident images (the ones with 8xxxxxxx addresses) -- how exactly did
you checksum those? But rebooting would have refreshed them...
The traceback seems to implicate the "call exit". Can you step through that on the
customer's system?
|
| 1836.4 | | LOWFAT::DIETER | | Tue Feb 11 1997 09:21 | 15 |
|
> The program fails with an ACCVIO from RUN/DEBUG or RUN/NODEBUG. If the
> image is linked /NODEBUG, the program executes without error.
Ususally, this symptom indicates a memory problem. (Hard to believe in
this case, with such a simple program, although the RTLs may contain the
problem, as that is where the ACCVIO is...)
In general, if you link /DEBUG, your .EXE contains all the debug information,
which causes a different layout in memory than if your program is linked
/NODEBUG. This difference in memory is what eventually leads to the ACCVIO
in one case but not the other, not the fact that the debugger is being
invoked or not.
Mary
|
| 1836.5 | Not Likely The Debugger... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed Feb 12 1997 10:28 | 18 |
|
Any DEBUG or LIB$DEBUG or TRACE or LIB$TRACE logical names around?
When an image is RUN/NODEBUG, the only `unusual' component `loaded'
is the debugger bootstrap -- this bootstrap is what loads the debugger
and passes it control, or loads and sets up the traceback handler.
(The debugger bootstrap is loaded when *any* image not specifically
LINK/NOTRACE/NODEBUG is run.)
This does look like a Fortran or FORRTL bug -- it's certainly
possible the Fortran compiler is generating bad code for this
routine and this bad code is visible when compiled /DEBUG.
(I'd also look at the final exit status being passed back to DCL
by the code -- it's been sufficiently long since I've worked in
Fortran that I don't remember the language syntax around the
Fortran `call exit' construct. Make sure this value is set to
some reasonable value, like 1, and not something spurious.)
|
| 1836.6 | | CSC32::HENNING | A rose with no thorns | Fri Feb 14 1997 12:53 | 2 |
| FYI -- problem was resolved by installing ALPSYS19_061, which replaced
IMAGE_MANAGEMENT.EXE.
|
| 1836.7 | | SSPADE::ARSENAULT | | Fri Feb 14 1997 15:57 | 1 |
| What was the problem? Do you understand why this was happening?
|
| 1836.8 | | CSC32::HENNING | A rose with no thorns | Mon Feb 17 1997 12:18 | 5 |
| > What was the problem? Do you understand why this was happening?
Not fully. However, ALPSHAD09_061 addressed a problem with debug
traceback. It was recommended that ALPSYS17_061 be installed with
ALPSHAD09_061. When the customer did this, the problem was resolved.
|
| 1836.8 | | CSC32::HENNING | A rose with no thorns | Tue Feb 18 1997 08:30 | 10 |
| > What was the problem? Do you understand why this was happening?
Not fully. However, 2 factors may be involved:
* ALPSYS15_061 "addressed" a problem that caused spurious SS$_SUBTRACED
errors in protected subsystems. Kit ALPSYS19_061 removed this fix,
since images linked /DEBUG couldn't run with this modification.
* ALPSHAD09_061 addressed a problem with debug traceback. It was
recommended that ALPSYS17_061 be installed with ALPSHAD09_061.
|