A bug problem.

[dedndave]

hard to say - lol
at this point, i don't think he really knows if it's fixed or not
i hate those kind of problems

[dedndave]

i had a little bug in my program today
i wanted to monitor some values as i scrolled, zoomed, sized around an image

Beep wasn't the answer
Olly wasn't either - the values i wanted to watch change too often
MessageBox would have been a pain in the ass

as it turned out, i already had a routine set up to display the X and Y locations in the status bar
a quick little mod - and i was observing the values i wanted easily in the status bar
if you don't happen to have a status bar set up - you can display a certain amount of info in the title bar

[minor28]

I usually use the title page to get information. But there are problems with that too when the strings are changing rapidly and the app closes itself without triggering the debugger. Then I added the sleep function that is increasing with an increase that depends on how long the app is running before the error occurs.

[dedndave]

well - this wasn't a crash error
i just had a small error in calculating the width of a zoomed image
it's fixed now - the status bar made it quick and easy to debug - that's why i mentioned it

[KeepingRealBusy]

I have gone through each memory block and I've used both beep and messagebox. I could not find anything wrong in handling the memory.

It took quite a long time but when I did the review I did some changes in the codes dealing with the strings and suddenly it worked. I cannot reproduce the bug so I don't know what was wrong. I don't think it was an unbalanced stack problem. Probably a memory problem anyway. Perhaps I was careless with a trailing zero somewhere.

Thank you for your help

Whenever I run into such debug situations, I save the entire directory as a different directory. Then play around until the problem goes away or I really found a single bug that caused it. If I am unsure what the real cause is, I then do a source code compare of the failing code and the "fixed' code to see what I really changed. It's real easy to delete the entire directory when no longer needed, impossible to second guess what might have fixed it if there was no temp save. As a last resort (with the save), back out the different changes one at a time and see where it starts to fail again, and don't back these out of the save directory, copy it to a third directory.

Dave.

[nixeagle]

I have gone through each memory block and I've used both beep and messagebox. I could not find anything wrong in handling the memory.

It took quite a long time but when I did the review I did some changes in the codes dealing with the strings and suddenly it worked. I cannot reproduce the bug so I don't know what was wrong. I don't think it was an unbalanced stack problem. Probably a memory problem anyway. Perhaps I was careless with a trailing zero somewhere.

Thank you for your help

Whenever I run into such debug situations, I save the entire directory as a different directory. Then play around until the problem goes away or I really found a single bug that caused it. If I am unsure what the real cause is, I then do a source code compare of the failing code and the "fixed' code to see what I really changed. It's real easy to delete the entire directory when no longer needed, impossible to second guess what might have fixed it if there was no temp save. As a last resort (with the save), back out the different changes one at a time and see where it starts to fail again, and don't back these out of the save directory, copy it to a third directory.

Dave.

Alternatively, make use of a version control system. I use git (git-scm.com/).

[minor28]

I localized the problem to a specific memory block allocated with HeapAlloc.
I use it to store zero terminated words, a word list. When a new word is
about to be added I first check if it not allready is present in the list.   

I tested different approaches to solve the problem. The only thing working was not to write
to the memory block. Then I studied what Masm32 library reference writes about
StrLen.

It appears that the condition does not generate a GP fault in windows as memory
is usually alocated in 4 byte blocks.

So I tested to change the first line below from StrLen to lstrlen function and then it worked.
Each word in the list is allways terminated with a zero. The problem might be in the StrLen code.
I have not studied the StrLen code.

Code:

@nextword:
invoke StrLen,esi ;length of a word in the list
;changed to
invoke lstrlen,esi ;length of a word in the list
.if eax==0
;not found
invoke HeapSize,hHeap,HEAP_NO_SERIALIZE,pWordList
push eax ;size of current memory block
push eax

invoke StrLen,edi ;length of new word
pop ecx
add eax,ecx
inc eax ;space for next terminationg zero

;Reallocate memory block
invoke HeapReAlloc,hHeap,HEAP_ZERO_MEMORY,pWordList,eax
.if eax==STATUS_NO_MEMORY || eax==STATUS_ACCESS_VIOLATION
invoke HeapExceptionFunction,eax
.else
mov pWordList,eax
mov esi,eax
.endif

pop eax ;size of previous memory block
add esi,eax ;address to end of previous memory block
.while byte ptr [esi]==0
dec esi
.if esi==pWordList && byte ptr [esi]==0
jmp @F ;word could be only one char
.endif
.endw
inc esi ;terminating zero for the previous word
inc esi ;address to start of next word
@@:
mov al,byte ptr [edi]
.while al!=0
mov byte ptr [esi],al
inc esi
inc edi
mov al,byte ptr [edi]
.endw
mov byte ptr [esi],0
xor eax,eax

.else
push eax ;length of word in list
invoke lstrcmp,edi,esi
.if eax==0
add esp,4
;code to handle the duplicated word
mov eax,1
.else
pop eax
add esi,eax
inc esi ;termination zero
jmp @nextword
.endif
.endif

[dedndave]

StrLen accesses the string data in dword chunks
that's part of the reason it's fast   
i don't remember if it aligns itself or not - that would hurt on short strings

but - it's fairly common to allocate as many as 16 bytes more than you need for a buffer - maybe even more
that may sound wasteful - but 16 bytes is trivial, even if the user only has 1 Gb RAM
in fact, i think HeapAlloc may do that for you
you ask for 12 and get 16
however - if you use HEAP_ZERO_MEMORY, don't expect them to be zeros
i think it was Ray Chen that had an article on this subject
the real danger is if you use HeapRealloc with HEAP_ZERO_MEMORY to enlarge the block
it will give you the new bytes - and zero most of them   
but if you originally asked for 12 and got 16....
....then ask for 28 more (filled with zeros) - it won't zero out the extra 4 it gave you to begin with

[jj2007]

That's a known problem indeed.

Try MasmBasic Len(), it's safe until the last byte. You can test it with your code by just replacing masm32rt.inc and adding the little macro that substitutes len() with the MasmBasic equivalent Len().

; include \masm32\include\masm32rt.inc
include \masm32\MasmBasic\MasmBasic.inc   ; download
len MACRO arg
  EXITM <Len(arg)>
ENDM
.data
MyStr   db "Just a string", 0
.code
start:
   inkey str$(len(offset MyStr))
   exit
end start

But, as Dave rightly wrote, asking for a few bytes more is an equally valid approach

[jj2007]

Try MasmBasic Len(), it's safe until the last byte.

I am afraid that was not true. You would trigger an exception under certain circumstances, for example: by reading a file that is 4096 bytes long into a VirtualAlloc'ed buffer of the same size. If you could imagine this rare situation happen, activate the SEH handler as shown below and attached.

include \masm32\MasmBasic\MasmBasic.inc   ; download
MbUseErrLine=1   ; increases code size but good for runtime error debugging
   Init tc   ; install the handler
   mov MbFlags[4], 1   ; a hack to force console output of non-continuable exceptions

   FileWrite "test.txt", String$(4096, "x")   ; prepare a nasty example

   invoke filesize, chr$("test.txt")
   xchg eax, ebx
   Print Str$("%i bytes in file\n\n", ebx)   ; this file is exactly one page long
   invoke VirtualAlloc, 0, ebx, MEM_COMMIT, PAGE_READWRITE
   xchg eax, edi
   invoke _lopen, chr$("test.txt"), OF_READ
   push eax
   invoke _lread, eax, edi, ebx
   call _lclose

   Print Str$("MasmBasic says the len of string is %i bytes\n", Len(edi))

   PrintLine "Now trying crt_strlen:"

   SetErrLine
   invoke crt_strlen, edi
   Print Str$("crt_strlen says the len of string is %i bytes\n", eax)   ; you will not see this message

   Inkey
   Exit
   TryCatchEnd   ; activate the handler - must be last instruction before "end start"
end start

Output:

Code:

4096 bytes in file

MasmBasic says the len of string is 4096 bytes
Now trying crt_strlen:


Exception (line 23?):
Code    C0000005
EIP     77C178C0

More on Try/Catch/Finally here.

[dedndave]

glad we could help   

[minor28]

I thank both you,

lstrlen seems to be reliable enough for me so I have change all StrLen to lstrlen.

[jj2007]

For the specific case of a 4096 byte string fitting exactly into the VirtualAlloc'ed buffer,

- lstrlen reports 0 bytes,
- StrLen and crt_strlen throw exceptions,
- MasmBasic Len() reports 4096 bytes.

The best recipe is avoiding this scenario 

[dedndave]

ok - another fine troubleshooting aide   
i wanted to know what the sequence was for WM_VSCROLL messages
my mouse driver translates wheel movement into scroll messages
and - i want to support wheel messages myself, ignoring the driver's aliasing
the scroll notifications are numbered 0 through 8

so - i used a bit of old-school stuff   

Code:

MorseNum PROC

;sends morse code representing a number from 0 to 9

MorseTime = 80

        and     eax,0Fh
        cmp     al,9
        ja      Morse8

        push    ebx
        push    esi
        push    edi
        mov     ebx,eax
        mov     esi,5
        mov     edi,10
        cmp     bl,5
        jbe     Morse0

        mov     bl,bh

Morse0: sub     edi,eax
        cmp     edi,4
        jbe     Morse1

        xor     edi,edi

Morse1: sub     esi,ebx
        sub     esi,edi
        or      ebx,ebx
        jz      Morse3

Morse2: INVOKE  Beep,750,MorseTime
        INVOKE  Beep,32000,MorseTime
        sub     ebx,1
        jnz     Morse2

Morse3: or      esi,esi
        jz      Morse5

Morse4: INVOKE  Beep,750,3*MorseTime
        INVOKE  Beep,32000,MorseTime
        sub     esi,1
        jnz     Morse4

Morse5: or      edi,edi
        jz      Morse7

Morse6: INVOKE  Beep,750,MorseTime
        INVOKE  Beep,32000,MorseTime
        sub     edi,1
        jnz     Morse6

Morse7: INVOKE  Beep,32000,2*MorseTime
        pop     edi
        pop     esi
        pop     ebx

Morse8: ret

MorseNum ENDP

[jj2007]

INVOKE  Beep, 32000, MorseTime

32,000 Hz? Either your dog barks the Morse code for you, or you are just a few months old, Dave