🚀 go-pugleaf

After even further thought, I'm a little surprised that the debugger 
wouldn't have removed that breakpoint when it stopped, thus causing memory 
to match what it was displaying as what should be there, although, at the 
same time, I'm happy it didn't, because if it did I wouldn't have been able 
to read it with the external program and (eventually) see what was happening 
to me...  So that, I suppose, might still be considered an IDE/debugger bug, 
as its left a process image in a state other than what it displays, but I 
suppose that can be considered the prerogative of the debugger, and maybe 
even, at least in this case, a good thing.

Perhaps it treats the traps of coded int 3's differently from the 
breakpoints it sets, in this regard (or not - but right now I don't feel 
like trying to figure that out.)

"dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:48805fcf$1@newsgroups.borland.com...
> And it just occurred to me that 0xcc is an int 3 instruction...
>
> And further occurred to me to check my breakpoints.  Sure enough, I have 
> an address breakpoint set with that value (two of them it seems.)
>
> So I guess it's my fault after all, not bds2006.
>
> "dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
> news:488047c1$1@newsgroups.borland.com...
>> This issue is partially resolved.  It's apparently a bds2006 debugger 
>> issue.
>>
>> Using a hacked program to externally read the debuggee process memory 
>> after a bogus trip (in the filler region being checked by bytesOK) shows 
>> that, in fact, the byte at that particular location is _NOT_ what the 
>> debugger is displaying in the CPU pane.  The debugger is displaying 0xff