Pages: 1 [2] 3
|
 |
|
Author
|
Topic: A bug problem. (Read 21122 times)
|
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
|
|
|
Logged
|
|
|
|
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
|
|
|
Logged
|
|
|
|
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.
|
|
|
Logged
|
|
|
|
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
|
|
|
Logged
|
|
|
|
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.
|
|
|
Logged
|
|
|
|
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/).
|
|
|
Logged
|
|
|
|
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. @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
|
|
|
Logged
|
|
|
|
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
|
|
|
Logged
|
|
|
|
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 ; downloadlen MACRO arg EXITM < Len(arg)> ENDM .data MyStr db "Just a string", 0 .code start: inkey str$(len(offset MyStr)) exitend start But, as Dave rightly wrote, asking for a few bytes more is an equally valid approach 
|
|
|
Logged
|
|
|
|
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 ; downloadMbUseErrLine=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: 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.
|
|
|
Logged
|
|
|
|
|
minor28
|
I thank both you,
lstrlen seems to be reliable enough for me so I have change all StrLen to lstrlen.
|
|
|
Logged
|
|
|
|
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 
|
|
|
Logged
|
|
|
|
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  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
|
|
|
Logged
|
|
|
|
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 
|
|
|
Logged
|
|
|
|
|
Pages: 1 [2] 3
|
|
|
 |