The following program fails in assembly
.686p
.model flat, stdcall
option casemap :none ; case sensitive
.xmm
.data
ProgName db "Uasm Test",0
.code
.nolist
include windows.inc
.code
Program:
invoke ExitProcess, 0
end Program
The output:
UASM v2.41, Sep 29 2017, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
***********
ASCII build
***********
F:\masm32\INCLUDE\winextra.inc(25183) : Error A2169: General Failure
F:\masm32\INCLUDE\winextra.inc(25183): Included by
F:\masm32\INCLUDE\windows.inc(26889): Included by
R:\bugtest\Sol.asm(10): Main line code
If I take out the .nolist, I get
F:\masm32\INCLUDE\windows.inc(21253) : Error A2169: General Failure
F:\masm32\INCLUDE\windows.inc(21253): Included by
R:\bugtest\Sol.asm(10): Main line code
So I really don't know how to pin down the error much more without stripping stuff out of windows.inc
I downloaded and installed the latest masm32v11r.zip to get windows.inc and winextra.inc to be sure mine weren't corrupted. They were identical, so that's not the problem.
It fails also for me:
UAsm64, latest build of today:
Tmp_File.asm(14) : Error A2160: INVOKE requires prototype for procedure
ML 6.15:
tmp_file.asm(14) : error A2006: undefined symbol : ExitProcess
okay-
same error with this program:
.686p
.model flat, stdcall
option casemap:none
.code
include R:\bugtest\windows.inc
.code
Program:
ret
end Program
no more invoke.
I'll work on this later this afternoon
now I am busy with 32bit -> 64bit RECORD :dazzled:
No problem. I'm grateful for all you do 8)
Anyway, I just spent hours deleting stuff out of windows.inc and the problem seems to be more like it is a Uasm internal buffer problem, rather than something specific with the actual code. "Seems" being the operative word, I can't absolutely confirm yet.
Try harder, it is easy to fix the problem ones when we know what it is ;)
Jim,
It could be related to
a) symbol ExitProcess missing (no kernel32.inc) and
b) includes and source on different drives
But of course, "general failure" is never a nice feedback :(
Quote from: jimg on October 02, 2017, 11:10:39 AM
okay-
same error with this program:
.686p
.model flat, stdcall
option casemap:none
.code
include \masm32\include\windows.inc
.code
Program:
ret
end Program
no more invoke.
This works here.
Make sure you build with:
uasm64 -c -coff jimg.asm
link /SUBSYSTEM:console jimg.obj
Thanks aw27 :t
I used /c /coff /Cp /Fl /Sn /Sg
jj-
I moved everything into one folder on a different drive with same results
I deleted winextra, and started deleting stuff from within windows.inc until it's down to 449 kb so far.
It's very touchy. Sometimes I delete a block and it works. I put that block back in, it doesn't work.
I delete a different block, sometimes it works, sometimes not.
At one point, it got so if I deleted a single blank line, it would work, but if I put the blank line back in it failed.
Which is why I think it is some kind of internal buffer/pointer problem.
*** Assemble using \masm32\bin\UAsm64 /c /coff /c /coff /Cp /Fl /Sn /Sg tmp_file.asm ***
UASM v2.41, Oct 1 2017, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
***********
ASCII build
***********
Tmp_File.asm: 9 lines, 2 passes, 91 ms, 0 warnings, 0 errors
Only change to your code:
include R:\bugtest\windows.inc
to
include C:\Masm32\include\windows.inc
I use UAsm64 by default, and assemble a dozen different sources every day. No such problems in the last six months or so...
I have to say I've not been able to re-produce this error under any conditions using any of the various includes.
Given that it seems to be random I don't believe it has much to do with the specific file in question, it definitely sounds like some sort of memory corruption or buffer overrun issue.
What OS/versions/ram size etc ? Perhaps I need to try a different test combination if there is something else causing interference.
While you were testing, so was I and I came to a similar conclusion.
I put everything in a single folder, including uasm32.exe, so there were no different drives drives involved.
if I assemble with-
uasm32 /c /coff /Cp /Fl /Sn /Sg "Sol.asm"
it works,but if I assemble with
uasm32 /c /coff /Cp /Fl /Sn /Sg ".\Sol.asm"
it fails.
Similarly, if I use the above line that worked, but change the include line to
include windows.inc
it works, but if I use
include R:\bugtest\windows.inc
it fails, even though it is the same file.
So I changed the name of the include file to be sure it wasn't referencing the masm32 include folder somehow, and got totally different results using the above tests, but it still fails. I'm putting together as simple a test as I can to upload.
Quote from: johnsa on October 03, 2017, 01:53:40 AMGiven that it seems to be random
For Jim, it doesn't seem so random. Does the "general failure" result from a SEH? If yes, can that be switched off for testing, so that Jim gets to see the offending line in the Just-in-time debugger? JIT works fine with x64dbg.
Since John found the problem, I'm deleteing the huge worthless attachment.
Ok,
I've managed to replicate the issue with uasm32..
uasm64 produces:
D:\pointy>c:\jwasm\uasm64 /c /coff /Cp /Fl /Sn /Sg jimg.asm
UASM v2.41, Oct 2 2017, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
***********
ASCII build
***********
jimg.asm: 9 lines, 2 passes, 68 ms, 0 warnings, 0 errors
while uasm32 for me yields:
D:\pointy>c:\jwasm\uasm32 /c /coff /Cp /Fl /Sn /Sg jimg.asm
UASM v2.41, Sep 29 2017, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
***********
ASCII build
***********
D:\masm32\include\windows.inc(21253) : Error A2169: General Failure
D:\masm32\include\windows.inc(21253): Included by
jimg.asm(5): Main line code
Now at least I have something to trace :)
Problem found and fixed :) It was a missing brace in a block of code added for 2.41.. ;)
Updated packages will be available soon after some more testing of all this new record fun.
New packages are up on the site with the fix for this (dated 03-10-2017).
Cheers
John
All fixed. Thanks :biggrin: