From: diewald@virrus.zko.dec.com (Jeff Diewald)
Subject: Re: Why does this code crash with ACCVIO? (summary, solution)
Reply-To: diewald@virrus.zko.dec.com (Jeff Diewald)
Organization: Digital Equipment Corporation
Date: Tue, 15 Dec 1992 15:04:30 GMT


In article <PRZEMEK.92Dec14171154@rrdstrad.nist.gov>, przemek@rrdstrad.nist.gov (Przemek Klosowski) writes:
|>Xref: nntpd.lkg.dec.com comp.os.vms:63422 vmsnet.internals:1684
|>Path: nntpd.lkg.dec.com!news.crl.dec.com!deccrl!caen!spool.mu.edu!uunet!dove!dove.nist.gov!przemek
|>From: przemek@rrdstrad.nist.gov (Przemek Klosowski)
|>Newsgroups: comp.os.vms,vmsnet.internals
|>Subject: Re: Why does this code crash with ACCVIO? (summary, solution)
|>Message-ID: <PRZEMEK.92Dec14171154@rrdstrad.nist.gov>
|>Date: Mon, 14 Dec 92 17:11:54 EST
|>References: <PRZEMEK.92Dec9100328@rrdstrad.nist.gov>
|>Sender: news@dove.nist.gov
|>Followup-To: comp.os.vms
|>Organization: U. of Maryland/NIST
|>Lines: 62
|>In-reply-to: przemek@rrdstrad.nist.gov's message of 9 Dec 92 15:03:28 GMT
|>
|>Hello!
|>
|>Thanks to all who participated in this thread (a reminder: my C
|>program was crashing because of an access violation on a simple
|>variable assignment, whereas the debugger executed the assignment
|>with no problems).
|>
|>Several folks:
|>  Arne Vajhxj <ARNE@ko.hhs.dk>
|> "D_North@onDEC.LoneStar.Org" <d_north@ondec.lonestar.org>
|>  rankin@eql.caltech.edu (Pat Rankin)
|>  <SYSMGR@ipg.ph.kcl.ac.uk> Nigel Arnot
|>  mullens@jamsun.IC.ORNL.GOV (James A. Mullens)
|>pointed out that the debugger has R/W access to memory that is Read-only
|>to the user program, so at least one mystery is solved: there really
|>was an access violation, but the debugger didn't see it as such.
|>

Actually, this isn't the reason the program "worked" with the Debugger.

Despite our best efforts, the Debugger does affect the program being 
debugged.  (Leading to the so-called "Heisenbug" effect.)  In many of the 
Debugger implementations I know about, there is a small fragment of code that
resides in the process being debugged.  In VMS, this fragment of code is the
Debugger "kernel."

The kernel contains all those essential services needed by the Debugger to 
debug your code - it can set and remove breakpoints, read and write memory,
and so on.  The kernel acts as an exception handler for the program, 
intercepting everything before it gets to your program, in order to figure
out if it's a Debug artifact or an effect of your program.

The significantly larger part of the Debugger is the "main," which handles
the UI, command parsing, symbol table lookup and so on.  In earlier versions
of VMS (before 5.2, I believe), there was no separation between the kernel
and main.  Now there is - the main now resides in a separate process, in order
to have as small an effect on the debugged process as possible.

If you RUN/DEBUG, VMS activates the Debugger before it activates your program.
There's an extra frame or two on the call stack before control reaches your
program.  There are extra exception handlers.  The location of the program in
memory is subtly shifted due to the extra memory needed for the Debugger.
Before 5.2, with all the Debugger in the same process as the program, that 
was a significant change in a lot of things.

The reference to the memory location that caused the ACCVIO in one case and
not the other was simply that the reference WAS "valid" in the latter case.
It was probably pointing into memory that was being used by the Debugger.  
Debug can't stop you from doing this, just as it can't stop you from corrupting
the stack.  It's memory in YOUR process - even if it's being used by Debug.
There was no ACCVIO for the Debugger to catch.

Now - if the program used that space, and the space was critical to an 
important part of the Debugger, you'd notice - there'd be some sort of
weird problem where the Debugger goes totally strange.  A good fraction of
the bug reports we get are really the results of the user program clobbering
itself and/or the Debugger.  (Which is why, when you file bug reports on the
Debugger, we really have to get code examples that demonstrate the bug so we 
can reproduce it.)

The Debugger does play with memory accessing, but it's always changing 
something that's read/write temporarily into something that's only read.
This is for static watchpoint support.  If we protect a variable location and 
your program tries to write to that variable, we catch it, change the 
protection back, let the write happen and then let you know that the value has 
changed.

So - I hope that makes it clear what *really* happened with your program.      

-------------------------------------------------------------------------------
	Jeff Diewald			EASYNET:   VIRRUS::DIEWALD
	Debug group			INTERNET:  diewald@virrus.zko.dec.com
	Digital Equipment Corp.
Newsgroups: comp.os.vms