🚀 go-pugleaf

Look at this and see if it is close to what you want.


##########################################

bool BytesOK( unsigned char *pAddr, unsigned char bval, unsigned nbytes )
{
 if( nbytes )
 {
  _asm
  {
    cld
    mov   al, bval  // Value to compare
    mov   ecx, nbytes  // Number of bytes to compare
    mov   edi, pAddr // Address of buffer
    repe  scasb
    jz  ItsOK:
  }
  //if(!MM3AdminData.survivalmode)
  // if(MM3AdminData.callint3onerror) __asm int 3 ;
  return 0 ;
 }
 ItsOK:
 return 1 ;
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ASMButtonClick(TObject *Sender)
{
 long BytesOKCount = 0;
 long BytesNotOKCount = 0;

 unsigned char* Buffer[257] = { "AAB" };

 for( int a = 1; a < 10; a++ )
 {
  if( BytesOK(  Buffer[0], 'A', a ) )
  {
   BytesOKCount++;
  }
  else
  {
   BytesNotOKCount++;
  }
 }
}

##########################################

Larry Griffiths

"dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:487e5d3c$1@newsgroups.borland.com...
> (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)
>
>
>