murphys@cod.NOSC.MIL (Steven P. Murphy) (02/21/89)
How do you track down a run time null pointer assignment?
I have written a assembly language subroutine for QuickC, the
routine works ok, but when the program is over I get:
run-time error R6001
- null pointer assignment
I have tried tracing through it with CodeView, but no luck. So
does any one have any suggestions for locating the problem.
Thanks in advance
Murph,
-------------------------------------------
_ _ _ Clarke's law, 2nd varation:
' ) ) ) /
/ / / . . __ _ /_ "Any sufficiently advanced technology
/ ' (_(_/_/ (_/_)_/ /_ is indistinguishable from a rigged demo"
/
'
------------------------
S. P. Murphy
Internet: murphys@cod.nosc.mil UUCP: {ucbvax,hplabs}!sdcsvax!nosc!murphyscramer@optilink.UUCP (Clayton Cramer) (02/22/89)
In article <1413@cod.NOSC.MIL>, murphys@cod.NOSC.MIL (Steven P. Murphy) writes: > How do you track down a run time null pointer assignment? > > I have written a assembly language subroutine for QuickC, the > routine works ok, but when the program is over I get: > > > run-time error R6001 > - null pointer assignment > > I have tried tracing through it with CodeView, but no luck. So > does any one have any suggestions for locating the problem. > > Murph, What this message means is that when the program got ready to exit, it found that someone had altered the Microsoft copyright message at DS:0. The slowest but easiest way to find this program with CodeView is to set up a tracepoint like this: TPB DS:0 l20 Keep in mind that this will only work once you have reached main, and the DS register is established. Then start the program running, and go get a cup of coffee -- and maybe dinner, and maybe leave it running over night, but eventually it will find the bad function that is overwriting DS:0. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Disclaimer? You must be kidding! No company would hold opinions like mine!
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (02/22/89)
In article <977@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: ... stuff deleted ... >What this message means is that when the program got ready to exit, >it found that someone had altered the Microsoft copyright message >at DS:0. The slowest but easiest way to find this program with >CodeView is to set up a tracepoint like this: > > TPB DS:0 l20 If he can find a 386, he should get Turbo Debugger and use a hardware breakpoint. His program will run at full speed, but screech to a halt if anybody touches DS:0. Duncan Murdoch
NU013809@NDSUVM1.BITNET (Greg Wettstein) (03/02/89)
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