search

LADSoft / OrangeC

OrangeC Compiler And Tool Chain
http://ladsoft.tripod.com/orange_c_compiler.html
Other
291 stars 39 forks source link

[AppVeyor] `omake` crashed #941

Closed ghost closed 1 year ago

ghost commented 1 year ago

Only happens with AppVeyor omake, Github Actions omake doesn't crash.

Related issue: #919

The different is we only run omake but not omake -f GNUmakefile like on #919 so omake will process Makefile instead of GNUmakefile.

AppVeyor omake (crashed):

$ omake
version: 6.0.70.90
Command Line: D:\OrangeC\bin\omake.exe

Access Violation:(D:\OrangeC\bin\omake.exe)
CS:EIP 0023:0042ECB2  SS:ESP 002B:0262FE5C
EAX: 01D20598  EBX: 0058FA40  ECX: 01D449C8  EDX: 0262FF38  flags: 00010213
EBP: 0262FE68  ESI: 01D449C8  EDI: 0042EDF1
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

CS:EIP  65 A1 00 00 00 00 89 45 FC C7 45 F8 00 00 00 00

Stack trace:
                        42ecb2
                        42dec7
                        490556
                        42c75b
                        42ee4b
           KERNEL32.dll 75ec7c04
              ntdll.dll 777db90f
              ntdll.dll 777db8da

Github Actions omake (doesn't crash and correctly points out that gmake is not exist):

$ omake
        gmake -f GNUmakefile -j:1 --jobserver-auth=OMAKE3172
sh: line 1: gmake: command not found

Error makefile(2): commands returned error code 127

@LADSoft The build from Github Actions works fine. As you said the build from AppVeyor is Orange C built with itself. Something is seriously wrong with Orange C. (Note: I already said that on #905).

ghost commented 1 year ago

@chuggafan I have an impression that the binary compiled by Orange C has no exception handling, instead if will always spit a stack trace and simply crash. Or the code generation by Orange C is so wrong that caused it to crash. Please note, the omake compiled by MSVC from Github Actions doesn't crash.

LADSoft commented 1 year ago 
The build from Github Actions works fine. As you said the build from AppVeyor is Orange C built with itself. Something is seriously wrong with Orange C. (Note: I already said that on https://github.com/LADSoft/OrangeC/issues/905).

just another bug lol.... the last one was a weird issue where I added an integer to the LHS of an assignment and it threw off the code generation... but it is no different really than you saying this doesn't work on msys2 other than that it affects a weird code generation case rather than something else... I will look at it later...

LADSoft commented 1 year ago

hm can't duplicate. I went to https://ci.appveyor.com/project/LADSoft/orangec/build/job/q2o495kegpdx3qwh/artifacts and downloaded the zip file with the binaries in it. I extracted just the omake.exe and put it in \orangec\bin. Then I ran omake on the indicated makefile both in msys2 and in cmd.exe, worked both times. I did verify that the version of omake matches the version in the crashdump...

ghost commented 1 year ago

hm can't duplicate. I went to https://ci.appveyor.com/project/LADSoft/orangec/build/job/q2o495kegpdx3qwh/artifacts and downloaded the zip file with the binaries in it. I extracted just the omake.exe and put it in \orangec\bin. Then I ran omake on the indicated makefile both in msys2 and in cmd.exe, worked both times. I did verify that the version of omake matches the version in the crashdump...

You are running Windows 11 and the CI server is running Windows 10 (or even 11) but I'm running Windows 8.1. Apart from the hypothesis that Orange C generated invalid code I have another hypothesis, it's the import libraries. The import libraries were created by Orange C on the CI server running Windows 10 or Windows 11, they contain functions not available on my Windows 8.1 or these functions simply changed on modern versions of Windows. The result is the Orange C versions built on the CI server that were linked with the import libraries also generated on that CI server failed to work as expected on my Windows 8.1. I want to test this hypothesis by trying to compile Orange C with itself on my computer. But it failed. See: #943.

p/s: the reason the Orange C compiled by MSVC even though also compiled on a modern version of Windows but still working fine on my Windows 8.1 is, I think, the Orange C binaries were compiled by MSVC and linked with the MSVC import libraries.

ghost commented 1 year ago

I don't want to invest on this any further. I will simply use the version from Github Actions or compile my own.

LADSoft commented 1 year ago

At some point when there were problems with windows 8.1 and omake, I tried to get out my old windows 8.1 computer to try to diagnose it properly. Unfortunately, I don't know the password. So if the problem truly is with windows 8.1 there is nothing I can do to debug it...

as far as import libraries, yes orange c does use its own, and I suppose there could be an incompatibility. I will check it out but not tonite...

ghost commented 1 year ago

At some point when there were problems with windows 8.1 and omake, I tried to get out my old windows 8.1 computer to try to diagnose it properly. Unfortunately, I don't know the password. So if the problem truly is with windows 8.1 there is nothing I can do to debug it...

as far as import libraries, yes orange c does use its own, and I suppose there could be an incompatibility. I will check it out but not tonite...

I could give you the files you need. Tell me which files. Do I need to upload all .l files? There are only 7 of them. Not much. I could compress them to a zip file and attach it here.

Update: it seems the import libraries are generated using these .def files:

https://github.com/LADSoft/OrangeC/tree/master/src/clibs/platform/win32/def

If it's the case then they are the same regardless of Windows versions.

Please correct me if I'm wrong.

LADSoft commented 1 year ago

yes you are right, the .def files should be the same regardless of windows version, with two caveats:

1) if I had mistakenly done import by number I'm not 100% sure if the numbers stay the same across windows versions 2) if I'm using a function that isn't available on windows 8.1 then there would be problems HOWEVER I would expect the operating system to pop up some kind of dialog if it couldn't resolve an import.

I looked at the executable and the imports are being done by name, so that is kosher... and I looked at documentation for all the functions in the import table that I thought had been added in later versions of windows, but it looked like we weren't using anything that was added later than Windows Vista...

so whatever the problem is I don't think it is related to the imports...

GitMensch commented 1 year ago

To the second: I've seen direct crashes for this, as those imports are often resolved using ordinals in the dlls which may crash is the dll is found but the ordinal isn't.

LADSoft commented 1 year ago

Orangec doesn't fill in the ordinals (leaves them set to zero) so do you think it would still try resolving by ordinal?

ghost commented 1 year ago

Latest Orange C build from AppVeyor:

$ omake
version: 6.0.70.93
Command Line: C:\OrangeC\bin\omake.exe

Access Violation:(C:\OrangeC\bin\omake.exe)
CS:EIP 0023:0042ECB2  SS:ESP 002B:0069FE5C
EAX: 01F30588  EBX: 00590A40  ECX: 01F53FC8  EDX: 0069FF38  flags: 00010213
EBP: 0069FE68  ESI: 01F53FC8  EDI: 0042EDF1
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

CS:EIP  65 A1 00 00 00 00 89 45 FC C7 45 F8 00 00 00 00

Stack trace:
                        42ecb2
                        42dec7
                        4902c8
                        42c75b
                        42ee4b
           KERNEL32.dll 774a7c04
              ntdll.dll 779bb90f
              ntdll.dll 779bb8da
$ omake -f GNUmakefile
version: 6.0.70.93
Command Line: C:\OrangeC\bin\omake.exe -f GNUmakefile

Access Violation:(C:\OrangeC\bin\omake.exe)
CS:EIP 0023:0042ECB2  SS:ESP 002B:025DFE5C
EAX: 01CA0598  EBX: 00590A40  ECX: 01CE42C8  EDX: 025DFF38  flags: 00010213
EBP: 025DFE68  ESI: 01CE42C8  EDI: 0042EDF1
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

CS:EIP  65 A1 00 00 00 00 89 45 FC C7 45 F8 00 00 00 00

Stack trace:
                        42ecb2
                        42dec7
                        4902c8
                        42c75b
                        42ee4b
           KERNEL32.dll 774a7c04
              ntdll.dll 779bb90f
              ntdll.dll 779bb8da
$ omake -f GNUmakefile2
version: 6.0.70.93
Command Line: C:\OrangeC\bin\omake.exe -f GNUmakefile2

Access Violation:(C:\OrangeC\bin\omake.exe)
CS:EIP 0023:0042ECB2  SS:ESP 002B:009EFE5C
EAX: 01E40598  EBX: 00590A40  ECX: 01E84048  EDX: 009EFF38  flags: 00010213
EBP: 009EFE68  ESI: 01E84048  EDI: 0042EDF1
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

CS:EIP  65 A1 00 00 00 00 89 45 FC C7 45 F8 00 00 00 00

Stack trace:
                        42ecb2
                        42dec7
                        4902c8
                        42c75b
                        42ee4b
           KERNEL32.dll 774a7c04
              ntdll.dll 779bb90f
              ntdll.dll 779bb8da
GitMensch commented 1 year ago

I don't know, but after linking they are likely in. Not sure but opening the door with dependencies.exe on the system that chrashes may (or may not) show some issues.

ghost commented 1 year ago

I don't know, but after linking they are likely in. Not sure but opening the door with dependencies.exe on the system that chrashes may (or may not) show some issues.

Tried with both the original Dependency Walker and the .NET based Dependencies, both don't show anything abnormal.

GitMensch commented 1 year ago

Thank you that's useful, one thing more to consider checked.

Can you run the broken binaries with a native debugger (WinDbg perhaps) and share the details on failure, too?

ghost commented 1 year ago

Thank you that's useful, one thing more to consider checked. Can you run the broken binaries with a native debugger (WinDbg perhaps) and share the details on failure, too?

No. I'm unable to install Visual Studio. I also don't want to invest on this any further.

LADSoft commented 1 year ago

@ghost, tonite I will build the commit for build 93 locally; it probably won't crash but given the crash dump above I can at least look through the binary and try to figure out where it crashed... maybe that will be a clue as to why. Stay tuned...

ghost commented 1 year ago

@LADSoft You should do that from the beginning. You have all of the tools needed while I have nothing. You instead let me searched in vain and wasted my time. I have no interest in omake anymore. This is your own problem now. Don't expect any feedback from me.

LADSoft commented 1 year ago

@iahung2 - For what it is worth, I am not perfect, I don't think of everything, all the time, in a timely fashion. Actually, I'm kinda tired of it being an expectation that I have to be live way so I'm just as glad see you go if that is the way it is going to be.

But I do think I fixed this finally.

Leaving is your right, but on the off-hand you want to read this I will just say I valued the input you gave and did the best I was able to do with it at the time.