I compiled, alt-tabbed, accidently pressed up/down/left/right keys in some random order, and it crashed:
State Dump for Thread Id 0x594
eax=00000007 ebx=0041b5d3 ecx=00000100 edx=00000000 esi=00000007 edi=00406320
eip=0040c734 esp=0006fe20 ebp=0006fe2c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
function: <nosymbols>
0040c718 c21400 ret 0x14
0040c71b c8000000 enter 0x0,0x0
0040c71f 53 push ebx
0040c720 56 push esi
0040c721 57 push edi
0040c722 8b7508 mov esi,[ebp+0x8] ss:00b0d3fe=????????
0040c725 8b7d0c mov edi,[ebp+0xc] ss:00b0d3fe=????????
0040c728 bbd3b54100 mov ebx,0x41b5d3
0040c72d b900010000 mov ecx,0x100
0040c732 31d2 xor edx,edx
FAULT ->0040c734 ac lodsb ds:00000007=??
0040c735 3c20 cmp al,0x20
0040c737 7434 jz 0041036d
0040c739 3c3b cmp al,0x3b
0040c73b 0f8481000000 je 0040c7c2
0040c741 88c4 mov ah,al
0040c743 d7 xlat
0040c744 08c0 or al,al
0040c746 7454 jz 0040d09c
0040c748 09d2 or edx,edx
0040c74a 7519 jnz 00414765
0040c74c 80fc27 cmp ah,0x27
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0006FE2C 00408F77 00000007 00406320 00079B93 0000000A !<nosymbols>
0006FF00 77E12E98 01030224 00000100 00000028 01500001 !<nosymbols>
0006FF20 77E130E0 00407000 01030224 00000100 00000028 user32!ScrollDC
0006FFAC 77E15824 00405FA0 00000001 00409E6C 00405FA0 user32!ScrollDC
0006FFF0 00000000 00409C10 00000000 000000C8 00000100 user32!DispatchMessageA
*----> Raw Stack Dump <----*
0006fe20 20 64 40 00 ff ff ff ff - 54 a4 07 00 00 ff 06 00 d@.....T.......
0006fe30 77 8f 40 00 07 00 00 00 - 20 63 40 00 93 9b 07 00 w.@..... c@.....
0006fe40 0a 00 00 00 d1 9e 07 00 - 4d 8b 40 00 48 00 c3 00 ........M.@.H...
0006fe50 a0 5f 40 00 a8 5f 40 00 - 00 00 00 c0 00 00 79 00 ._@.._@.......y.
0006fe60 25 01 30 50 08 01 79 00 - 7b 02 00 00 a8 ba d8 00 %.0P..y.{.......
0006fe70 12 00 00 00 5f 01 00 00 - 70 50 d6 00 00 00 00 00 ...._...pP......
0006fe80 4d 01 00 00 00 00 00 00 - 12 00 00 00 5e 01 00 00 M...........^...
0006fe90 00 00 00 00 d4 14 0a 89 - 07 00 00 00 0e 00 00 00 ................
0006fea0 1a 00 00 00 10 96 07 00 - 53 00 00 00 1b 00 00 00 ........S.......
0006feb0 ff ff ff 00 00 00 00 00 - 00 16 2d 00 ff ff ff 00 ..........-.....
0006fec0 1b c7 40 00 a4 13 40 00 - 50 2b f8 00 00 08 f9 00 ..@...@.P+......
0006fed0 00 08 d9 00 f8 a3 d8 00 - 00 00 00 00 00 00 00 00 ................
0006fee0 7e 00 00 00 fc 00 00 00 - 00 00 00 ff 7e fb e1 77 ~...........~..w
0006fef0 00 00 00 00 28 00 00 00 - 01 00 50 01 00 b5 00 04 ....(.....P.....
0006ff00 20 ff 06 00 98 2e e1 77 - 24 02 03 01 00 01 00 00 ......w$.......
0006ff10 28 00 00 00 01 00 50 01 - a8 5f 40 00 cd ab ba dc (.....P.._@.....
0006ff20 ac ff 06 00 e0 30 e1 77 - 00 70 40 00 24 02 03 01 .....0.w.p@.$...
0006ff30 00 01 00 00 28 00 00 00 - 01 00 50 01 d3 b5 41 00 ....(.....P...A.
0006ff40 d6 0f 41 00 00 00 00 00 - 74 ff 06 00 01 00 50 01 ..A.....t.....P.
0006ff50 58 4a e2 77 00 00 00 00 - 00 00 00 00 04 00 00 00 XJ.w............
Thanks, I've been hunting for that mysterious bug for a long time. Hope this time I'll catch it. ;)
Altough this info still may not be enough, because the real bug probably occured earlier and caused some pointer to have invalid value, so in this place you've got a fault. It'd be great if you could provide me with some instructions how to reproduce that bug. Or at least give me the dump of whole process memory.
Altough this info still may not be enough, because the real bug probably occured earlier and caused some pointer to have invalid value, so in this place you've got a fault. It'd be great if you could provide me with some instructions how to reproduce that bug. Or at least give me the dump of whole process memory.
I set my Dr. Watson to generate dump file... I shall send it to you as soon as bug is reproduced.
Fasm crashed for me too at that point, I posted the dump files in the other thread (the save bug thread), perhaps that post should be here?
I have gotten the same crash again. This time I had Dr. Watson 32 configured to create dump. It is same bug on that lodsb with esi=7. The whole dump (compressed) is too large to send over, even via e-mail. Could we perhaps arrange some ICQ/MSN/Yahoo!/AIM/IRC transfer?
Finally! After a few hours of analysing the dump that comrade had made for me (BTW: bolshoie spasiba, tovarishch!) I've managed to reproduce that bug and find its origin. It's fixed now for the coming 1.47 version, but if anyone wants to have it corrected before the new release, here's the fix for the "store_line_for_undo" procedure in ASMEDIT.INC file:
And if you want to reproduce that bug in 1.46, do anything that will store the exact multiply of 32 lines in undo buffer (for example mark and delete any 31 full lines) and then do Undo command.
Now there's only that mysterious save bug left.
.store_line_for_undo:
pusha
cmp [.current_line],0
je .line_for_undo_ok
mov esi,[.undo_data]
or esi,esi
jz .line_for_undo_ok
mov esi,[esi]
mov ecx,[esi+4]
lea edi,[esi+8+ecx*8]
inc ecx
cmp ecx,20h
jbe .slot_ok
push esi
call .allocate_line
jc .out_of_memory
mov esi,eax
mov ebx,[.undo_data]
mov [ebx],esi
pop dword [esi]
mov ecx,1
lea edi,[esi+8]
.slot_ok:
mov [esi+4],ecx
mov esi,[.current_line]
mov eax,[esi]
cmp eax,-1
jne .store_line
stosd
mov eax,esi
stosd
jmp .line_for_undo_ok
.store_line:
call .allocate_line
jc .out_of_memory
mov ebx,eax
stosd
mov eax,[.current_line]
stosd
mov esi,eax
mov edi,ebx
mov ecx,108h shr 2
rep movsd
.line_for_undo_ok:
popa
ret
And if you want to reproduce that bug in 1.46, do anything that will store the exact multiply of 32 lines in undo buffer (for example mark and delete any 31 full lines) and then do Undo command.
Now there's only that mysterious save bug left.