Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running a C# project with a 32 bits binary on a 64 bits windows causes a crash #17299

Closed
LaurentOngaro opened this issue Mar 6, 2018 · 18 comments

Comments

@LaurentOngaro
Copy link

LaurentOngaro commented Mar 6, 2018

Godot version:
commit : SHA-1: 91ed678
(but occurs with previous versions too)

OS/device including version:
Microsoft Windows 10 Professionnel 64 Bits
OS Version: 10.0.16299 Numéro 16299
NVIDIA GeForce GTX 1060 6GB (driver Version 23.21.13.9077)

Issue description:
I've managed to compile the GODOT sources from github for windows x86 and x64 but only the 64 bits version of the editor (and export templates) can open and run a very basic C# project on my PC.
The 32 bits version of all the binaries crashes when I try to run the game (in the editor or after exporting to a 32 bits version).

Details and tested solutions:

  • both mono versions are installed and sync (anyway, I use the dlls created by the compilation).
    Note that exporting the C# project to win32 or win64 produce similar results: win64 runs well whereas win32 crashes
  • the generated Dlls and exe are copied to a specific folder between 32 and 64 build to avoid files replacement
  • the tested project is very basic: single scene with a sprite moved by script
  • I've tried to put the .sc file in each version of the editor to avoid conflicts that can appear if they share the same data folder.
  • removing the .mono folder in the project changes nothing on running but avoids a crash on opening.
  • the output window displays several "<couldn't map PC to fn name>" warnings just before crash

I think that maybe something is trying to load a 64bit dll in the 32bit environment.

This is the backtrace when a crash occurs:
OpenGL ES 3.0 Renderer: GeForce GTX 1060 6GB/PCIe/SSE2
Mono: Initializing module...
Mono: Runtime initialized
Mono: INITIALIZED
GO!
CrashHandlerException: Program crashed
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] mono_runtime_resource_limit
[1] <couldn't map PC to fn name>
[2] <couldn't map PC to fn name>
[3] <couldn't map PC to fn name>
[4] RtlRbInsertNodeEx
-- END OF BACKTRACE --

Steps to reproduce:

  1. Compile the source WITH MONO on a 64 bits windows system.
  2. Open and run a c# project with a 32 bits binary.

You can find the DOS batch file I use for compilation with Visual studio 2017 here:
https://gitlab.com/snippets/1701292

Minimal reproduction project:
BuildTest_CS.zip

@LaurentOngaro LaurentOngaro changed the title Running a C# project with a 32 bits binary on a 64 bit system causes a crash Running a C# project with a 32 bits binary on a 64 bits windows causes a crash Mar 6, 2018
@LaurentOngaro
Copy link
Author

message windows when a crash occurs

image

@akien-mga
Copy link
Member

CC @neikeq

@akien-mga akien-mga added this to the 3.1 milestone Mar 6, 2018
@LaurentOngaro
Copy link
Author

I've just tested it with the builds available here
https://downloads.tuxfamily.org/godotengine/3.0.2/mono
and ..... Same issue

@LaurentOngaro
Copy link
Author

Recently I've tested a build on a x86 windows 10 system from master branch and ....... Same issue.
So It doesn't seem to be a cross compiling issue

@exts
Copy link
Contributor

exts commented Jul 11, 2018

Reproduced on windows 10 64 bit system. Build using 3.0.5 stable and unchecked 64bit.

CC @hpvb

@Kiotenhariyo
Copy link

Same here win10
Can open projects created with 64bit Godot in 32bit Godot - ONLY if no "64bit" C# files exists in project.
Any project generated in 64 bit godot with C# files/solution crashes if opened in Godotmono 32bitmono

Have both 64 and 32 recommended mono versions installed

@exts
Copy link
Contributor

exts commented Jan 9, 2019

Reproduce again with 3.1 beta1 (cc: @hpvb @neikeq)

Stacktrace:

Memory around native instruction pointer (0242F775):
0242F765  11 00 12 00 13 00 14 00 15 00 16 00 17 00 18 00  ................
0242F775  ff ff 01 02 00 00 ff ff 01 08 00 00 01 00 02 00  ................
0242F785  03 00 ff ff 01 02 00 00 ff ff 01 00 ff ff 01 02  ................
0242F795  00 00 ff ff 01 02 00 00 ff ff 01 08 00 00 01 00  ................

=================================================================
Got a SIGILL while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

@akien-mga
Copy link
Member

Is this still reproducible in the latest beta build?

@exts
Copy link
Contributor

exts commented Feb 23, 2019

Still an issue with beta6 https://g4mr.itch.io/godotsharp-shooter look for 3.1beta6-win32-debug.7z

@exts
Copy link
Contributor

exts commented Feb 28, 2019

@akien-mga

image
image

You could probably move this to 3.2 for now as the 32bit editor exports 32bits correctly (at least there's a way to get these builds, just tedious atm), but this should definitely get looked at down the line.

@neikeq
Copy link
Member

neikeq commented Jul 25, 2019

I cannot reproduce it on latest master (Windows 10 64bits), building against Mono 6.0.0.313 32bit.
I can reproduce it with 3.1.1 stable, but I cannot get a backtrace (it doesn't get handled by our crash handler somehow).

@akien-mga akien-mga modified the milestones: 3.2, 4.0 Dec 13, 2019
@akien-mga akien-mga self-assigned this Dec 13, 2019
@exts
Copy link
Contributor

exts commented Dec 21, 2019

Still an issue with 3.2beta4 on windows 10.

@GeorgeS2019
Copy link

@akien-mga Thanks for taking care of ALL THINGS windows for Godot. Please try your best!

@neikeq
Copy link
Member

neikeq commented Jan 20, 2020

I can reproduce this with 3.2 RC2. However, there's no error or crash report, so it's not very helpful.

I just tried to build from source again with latest master (c3fd101) and MSVC 14.1. Mono version is 6.8.0.96.

Command:

scons.bat p=windows -j 3 target=debug tools=yes verbose=yes module_mono_enabled=yes bits=32 mono_prefix=PATH_TO_32_BIT_MONO_PREFIX mono_static=yes copy_mono_root=yes

I also tested without mono_static=yes. Make sure to include copy_mono_root=yes.

I could not reproduce any crash.

Please, if any one can still reproduce this when building with MSVC, try to include as much information as possible on the steps to reproduce. A backtrace from a debug build would also be welcome.

If no one else can reproduce this with MSVC, maybe it has something to do with the official builds, which use MinGW.

@LaurentOngaro
Copy link
Author

I'm not able to test it because I'm no longer on Windows, so I don't know if the bug is still present
I'm on Arch Linux now, and I cross compiling the binaries for windows

@akien-mga
Copy link
Member

@neikeq had some users test on Discord and they also didn't have issues when building with MSVC on Windows.

So something is faulty in our MinGW cross-compiled setup for 32-bit C# projects.

It's unlikely that we'll have time to dig into it for 3.2, so moving to the next milestone. If we find a fix we'll use it for future 3.2.x releases.

@akien-mga akien-mga modified the milestones: 3.2, 4.0 Jan 22, 2020
@akien-mga akien-mga added the cherrypick:3.x Considered for cherry-picking into a future 3.x release label Jan 22, 2020
@akien-mga
Copy link
Member

According to @piratesephiroth in #30689 (comment), the 32-bit Mono version now works on 64-bit Windows as of Godot 3.2.2. Can others confirm?

@akien-mga
Copy link
Member

akien-mga commented Sep 4, 2020

No answer, but I tested the 32-bit version of Godot 3.2.3 RC 5 on Windows 10 x64 and it seems to work just fine, so closing.
Please comment if you can still reproduce the issue.

@akien-mga akien-mga removed the cherrypick:3.x Considered for cherry-picking into a future 3.x release label Sep 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants