Index
> Main > fasm 1.65.17 hanging |
| Author |
|
|
Tomasz Grysztar 19 Mar 2006, 20:42
Which interface is it?
|
|||
19 Mar 2006, 20:42 |
|
|
Vortex 21 Mar 2006, 18:25
Fasm for Win32
_________________ Code it... That's all... |
|||
|
21 Mar 2006, 18:25 |
|
|
Tomasz Grysztar 21 Mar 2006, 18:28
Have you tried on different computers? Are you sure the executable is not corrupted in some way?
If nothing helps please try providing some more information that would help finding out what can be the source of problem. |
|||
|
21 Mar 2006, 18:28 |
|
|
revolution 22 Mar 2006, 00:12
I have no trouble with Win32 Console 1.65.17. Everything works fine for me.
Vortex: perhaps you can post the portion of code that is causing the trouble. |
|||
|
22 Mar 2006, 00:12 |
|
|
Madis731 22 Mar 2006, 07:52
Worksforme...
EDIT: Oh, specs = W2K SP4, FASMW 1.65.17 |
|||
|
22 Mar 2006, 07:52 |
|
|
LocoDelAssembly 22 Mar 2006, 10:07
It works for me too
OS: XP Pro SP2, RAM : 1 GB , CPU : Athlon64 - 2 GHz Athlon64 but using 32-bit OS... |
|||
|
22 Mar 2006, 10:07 |
|
|
Vortex 24 Mar 2006, 18:22
Unfortunately, fasm hangs also in my computer at work. It hangs even without specifiying source files:
Code: fasm /? _________________ Code it... That's all... |
|||
|
24 Mar 2006, 18:22 |
|
|
Vortex 24 Mar 2006, 18:30
Analyzing with Olydbg, I discovered the portion of the code entering in an infinite loop :
Code: 0040127E > 89C2 MOV EDX,EAX 00401280 . C1EA 02 SHR EDX,2 00401283 . 89C1 MOV ECX,EAX 00401285 . 29D1 SUB ECX,EDX 00401287 . 890D AC1D4100 MOV DWORD PTR DS:[411DAC],ECX 0040128D . 8915 B41D4100 MOV DWORD PTR DS:[411DB4],EDX 00401293 . 6A 04 PUSH 4 ; /Protect = PAGE_READWRITE 00401295 . 68 00100000 PUSH 1000 ; |AllocationType = MEM_COMMIT 0040129A . 50 PUSH EAX ; |Size 0040129B . 6A 00 PUSH 0 ; |Address = NULL 0040129D . FF15 4C804100 CALL DWORD PTR DS:[<&KERNEL32.VirtualAll>; \VirtualAlloc 004012A3 . 09C0 OR EAX,EAX 004012A5 . 74 1C JE SHORT FASM.004012C3 004012A7 . A3 A81D4100 MOV DWORD PTR DS:[411DA8],EAX 004012AC . 0305 AC1D4100 ADD EAX,DWORD PTR DS:[411DAC] 004012B2 . A3 AC1D4100 MOV DWORD PTR DS:[411DAC],EAX 004012B7 . A3 B01D4100 MOV DWORD PTR DS:[411DB0],EAX 004012BC . 0105 B41D4100 ADD DWORD PTR DS:[411DB4],EAX 004012C2 . C3 RETN 004012C3 > A1 B41D4100 MOV EAX,DWORD PTR DS:[411DB4] 004012C8 . C1E0 02 SHL EAX,2 004012CB . 3D 00400000 CMP EAX,4000 004012D0 . 0F82 CC040000 JB FASM.004017A2 004012D6 .^EB A6 JMP SHORT FASM.0040127E VirtualAlloc seems to fail always, this is why the application falls in an infinite loop. _________________ Code it... That's all... |
|||
|
24 Mar 2006, 18:30 |
|
|
Tomasz Grysztar 24 Mar 2006, 18:38
I see... please try the updated 1.65.17
What was the last older version that you tried? |
|||
|
24 Mar 2006, 18:38 |
|
|
Vortex 24 Mar 2006, 18:53
Hi Tomasz,
Thanks for your interest. The last version I used is V1.65.17 I got the same result with V1.65.13 The last time when I used Fasm to assemble my projects without any problem was february 19. It was probably the latest release of fasm version corresponding to this date. Notice that when I specify the amount of memory with the -m parameter , for example -m 100000 , fasm runs without any problem. It is necessary always to use this parameter? Probably, I am missing something with this -m switch. _________________ Code it... That's all... |
|||
|
24 Mar 2006, 18:53 |
|
|
Tomasz Grysztar 24 Mar 2006, 20:06
I did mean what was the last version that was working correctly for you (since I assume you changed into 1.65 from some version that was working from you and then it didn't work anymore).
Have you tried the updated 1.65.17? (version number stayed the same, only date changed) |
|||
|
24 Mar 2006, 20:06 |
|
|
Vortex 24 Mar 2006, 21:17
I downloaded the latest version dating march 24 and it works fine. Thanks for this new release.
_________________ Code it... That's all... |
|||
|
24 Mar 2006, 21:17 |
|
|
Madis731 25 Mar 2006, 09:18
Hi, Vortex. Why do you need 100MB of memory to assemble your projects? Or are the commandline switches different as in KBs?
The problem is that it just can't get enough memory allocated and the OS panics. While cleaning other system areas and increasing swap it loops the allocation process until it (FASM) is satisfied. If you have something like 2GB of memory then just ignore my answer, but this might well be the problem with less than 256MB of memory because Windows wants at least half of it (with default install). My "system cache" is 240MB at the moment. try: -m 16386 | -m 32768 or something in that lower range. If your OS doesn't swap then the whole assemblying goes faster. There are some projects that need more others that need less memory... Althought, it should note you "out of memory" - that IS strange... |
|||
|
25 Mar 2006, 09:18 |
|
|
Vortex 25 Mar 2006, 10:13
Hi Madis731,
The -m 100000 was a very quick trial to see if it solves the problem. My box has a memory of 2 GB so memory allocation should not be a problem. The latest fasm.exe released by Tomasz works fine without any problem. The previous one didn't emit any warning message such "out of memory" , simply the assembler entered in an infinte loop. _________________ Code it... That's all... |
|||
|
25 Mar 2006, 10:13 |
|
|
vid 26 Mar 2006, 22:56
yup, when malloc returns error, it doesn't always mean that it is because there is no memory! most of programmers are quite lazy on error checking, seems that even best ones
  |
|||
|
26 Mar 2006, 22:56 |
|
|
Tomasz Grysztar 26 Mar 2006, 23:17
The fasm's Win32 interface when it fails to allocate requested memory, reduces the size of request and tries again, until the size that it requested is no more than 4 KB - in such case it signalizes "out of memory". Recently I changed the distribution of allocated memory between the main and additional memory block, and this had the side-effect I overlooked, that the size reduction it was doing on allocation retry was actually no reduction at all (as you can see in the disassembly above, it was first doing SHR to get the size of additional memory block, and then on retry it was taking this size and doing SHL by the same amount on it), so it was trying allocating the same amount of memory all the time, thus the infinite loop.
|
|||
|
26 Mar 2006, 23:17 |
|
< Last Thread | Next Thread > |
Forum Rules:
|