Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!cunyvm!ndsuvm1.bitnet!nu013809
From: NU013809@NDSUVM1.BITNET (Greg Wettstein)
Newsgroups: comp.sys.ibm.pc
Subject: Re: null pointer assignment?
Message-ID: <1949NU013809@NDSUVM1>
Date: 2 Mar 89 15:24:51 GMT
References: <1413@cod.NOSC.MIL> <977@optilink.UUCP>
Organization: North Dakota Higher Education Computer Network, Fargo, ND
Lines: 29
DISCLAIMER: Author bears full responsibility for contents of this article.

I have had very good look tracking down null pointer assignment problems using
the memory trace feature in Codeview.  However as the previous poster mentioned
it can be a very slow process.

In reading the documentation that came with the version of Codeview packed with
5.1 of MSC I noticed a comment saying that using the /r switch would enable the
use of the 80386 hardware breakpoint registers.  These debug registers are
supposed to be much faster for tracking memory modifications, the only
restriction being that only 4 bytes (one word) of memory may be traced at a
time

I tried using this facility on my office computer (ALR/220 80386 @ 20 MHZ,
Phoenix BIOS, 80 Mbyte hard disk, 2Mbyte RAM, COMPAQ DOS 3.31) without much
success.  Codeview and the program worked but exiting Codeview after a debug
session resulted in a complete lockup of the system.  CTL-ALT-DEL had no effect
so a full power cycle was required.  The bug does not seem to be related to
program size only to invoking Codeview with the /r switch.

Has anybody experienced similar difficulties while trying to use this feature
with other 80386 based systems.  I am using the extra 1 Mbyte of RAM as a
RAMDISK using the /e (extended memory) switch on VDISK.SYS.  Could there be
some problem involved with trying to use the hardware debug registers with a
RAMDISK that is switching the processor in and out of protected mode?  Any
comments or recommendations would be appreciated.  Thanks in advance for any
help the net extends.

                                                 As always,
                                                 G.W. Wettstein
                                                 BITNET: NU013809@NDSUVM1