🚀 go-pugleaf

(Thanks in advance...  Sorry if this seems off-topic to some, but it really 
didn't seem non-technical in nature.)

1)Please report if you spot an error in the BytesOK() routine.  Its intended 
purposes is to scan the nbytes bytes starting at location pAddr, verifying 
that all of those bytes have value bval.  It does not explicitly clear 
direction flag, but CPU pane reports direction flag as clear (see further 
below.)  If it finds a non-conforming byte, it may generate an int3, and 
will return 1.
2)If the code does not have errors to cause functioning as other than 
specified, any reasonable guesses as to why it would trip, with the 
information in the CPU pane indicating it should not have indicated an 
error?
3)All observed paths leading to this routine are protected by a 
synchronization object (it could be reached from differing threads 
otherwise)
4)It's only been in the last few weeks that I've started to encounter this, 
but this code is part of a replacement heap manager, and is not always 
active, although it ususally is on my development machine (for the better 
part of the past year.)
5)The CPU disassembly pane does seem to correctly reflect the source written 
(if(_eax &0x4000) optimized to test ah, $40.)

When this trip occurs (periodically), on two occasions, chasing the stack by 
hand, I have found this in the stack as a seeming starting point (to freeing 
some memory):
vcl100.@Graphics@TBrush@$bdtr$qqrv:
52006AD0 53               push ebx
(I've only walked the stack by hand twice, so far...)

int BytesOK(unsigned char *pAddr, unsigned char bval, unsigned nbytes)
{
    unsigned ui ;
    _asm
    {
         cld
         mov   al, bval
         //apparently ecx is incremented whether or not compare eq or not...
         //so our test for non-zero ecx fails.
         mov   ecx, nbytes
         //We'll increment count of bytes, by one (1) - if actual filler 
compares
         //NE, ecx will be non-zero.  If only the extra byte doesn't 
compare, then
         //ecx should still be zero.  ***ASSUMPTION: There will always be at
         //least one readable byte beyond any block...
         //Probably bad, better find out where zero flag is and test that...
         //inc ecx
         mov   edi, pAddr
         repe  scasb
         lahf
         //now, which bit is the zero/equal bit?
    } ;
    //if(_ECX)
    if(!(_EAX & 0x4000)) //0x40 set in AH
    {
         if(!MM3AdminData.survivalmode)
            if(MM3AdminData.callint3onerror) __asm int 3 ;
         return 1 ;
    }
    return 0 ;
}


Mysteriously, BytesOK() routine trips calling int 3, with presented evidence 
indicating to me it had no reason to do so.  What might be happening?

pAddr == 0x044003e0
bval == 0xff
nbytes == 32

survivalmode == 0
callint3onerror == 1

cpu window shows ...
dump pane all bytes from 0x044003E0 through 0x044003FF as byte value 0xff 
(as desired expected)
ZF == 0 (although would have been blown away by two comparisons after the 
test ah, $40)
DF == 0
AL == 0xff
ECX == 0x7
EDI == 0x044003F9

code is protected by synchronization object at higher level, 
(AsFarAsICanSee) for all paths leading to this point...

XP SP2, intel P4 3.6GHz hyper-threaded 
(ACPI\GENUINEINTEL_-_X86_FAMILY_15_MODEL_4\_0)  (computer box about 2.5 
years old)