🚀 go-pugleaf

"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 // I do not think this is checking that ALL the 
characters are equal to what is in register al.

Larry