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

Game crash when using compatibility rendering method #79503

Closed
univeous opened this issue Jul 15, 2023 · 10 comments · Fixed by #79528
Closed

Game crash when using compatibility rendering method #79503

univeous opened this issue Jul 15, 2023 · 10 comments · Fixed by #79528

Comments

@univeous
Copy link
Contributor

univeous commented Jul 15, 2023

Godot version

4.1 and 4.0.3 debug build

System information

OS: Manjaro Linux x86_64
Kernel: 6.1.38-1-MANJARO
CPU: AMD Ryzen 5 5600X (12) @ 3.700GHz
GPU: NVIDIA GeForce RTX 3070 Ti
X11 backend
OpenGL API 3.3.0 NVIDIA 535.54.03

Issue description

Game crashes silently after switching to compatibility rendering method.
It's a pure 2D game. Forward+ and mobile work fine.

logs in console:

4.0.3 debug build:

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.3.stable.custom_build (5222a99f5d38cd5346254cefed8f65315bca4fcb)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x39ab0) [0x7fe425c9dab0] (??:0)
[2] /usr/lib/libGLdispatch.so.0(+0x4d6c9) [0x7fe4176de6c9] (??:0)
-- END OF BACKTRACE --
================================================================

4.1 official:

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.1.stable.official (970459615f6b2b4151742ec6d7ef8559f87fd5c5)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x39ab0) [0x7fc48dfd9ab0] (??:0)
[2] /usr/lib/libGLdispatch.so.0(+0x4d6c9) [0x7fc48462b6c9] (??:0)
-- END OF BACKTRACE --
================================================================

Steps to reproduce

Switch to compatibility rendering method and run game in editor.

Minimal reproduction project

signal11.zip

@AThousandShips
Copy link
Member

AThousandShips commented Jul 15, 2023

We need to know what is triggering this, so unless you can pin down what is causing it and make an MRP we can't help

You will need to pick apart your project, or add parts one by one, until you cause the crash reliably, and then update your report, or search through other reports and see if any matches what you're experiencing, or can give you hints

Unfortunately "it crashes with compatibility" doesn't give us any clues

@univeous
Copy link
Contributor Author

univeous commented Jul 15, 2023

I just uploaded an MRP. Actually it's not very related to 2D.
The following script will crash the game only in compatibility mode.

extends Node2D

@onready var thread := Thread.new()

func _ready():
	RenderingServer.get_video_adapter_name() # will not crash
	RenderingServer.get_video_adapter_vendor()
	thread.start(func():
		RenderingServer.get_video_adapter_name() # will crash here
		RenderingServer.get_video_adapter_vendor()
	)


func _exit_tree():
	thread.wait_to_finish()

@AThousandShips
Copy link
Member

AThousandShips commented Jul 15, 2023

Seems to be a limitation in the driver possibly, not the engine I suspect

Can't confirm on my hardware/drivers, I'm on Windows 11, AMD graphics

@TheYellowArchitect
Copy link
Contributor

I agree with the above. I managed to import the above project in 4.1, switch to compatibility renderer (which restarts the editor) and run the game (F5) without any problems

@clayjohn
Copy link
Member

clayjohn commented Jul 15, 2023

Related: #77929.

I can't reproduce on my hardware either. PopOS 22.04, intel integrated GPU.

I tested both 4.1-stable and 4.0.3

I wonder if this is related to multithreading specifically. It seems that those functions aren't part of the command queue, which means that they may be called from whichever thread the user script is called from

edit: If someone who can reproduce this wants to attempt a fix. A good first thing to try would be to make:

virtual String get_video_adapter_name() const override;
virtual String get_video_adapter_vendor() const override;
virtual RenderingDevice::DeviceType get_video_adapter_type() const override;
virtual String get_video_adapter_api_version() const override;

These functions (minus get_video_adapter_type) use the FUNC0R declaration format (you can see how other functions use it above)

@univeous
Copy link
Contributor Author

I wonder if this is related to multithreading specifically.

I think it is. the crash only happens when calling them in a thread.

@ghost
Copy link

ghost commented Jul 15, 2023

It does not crash on my system:

  • v4.1.stable.official.970459615
  • Windows 10.0.19045
  • Vulkan (Compatibility)
  • GeForce GT 540M
  • Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz (8 Threads)

However both of the RenderingServer functions in question return empty string only when run in a Thread.

@univeous
Copy link
Contributor Author

univeous commented Jul 15, 2023

I managed to fix this issue following @clayjohn sensei's instruction. Crashes are gone, although I'm not sure If I'm doing it right.

These functions (minus get_video_adapter_type)

Do you mean minus get_rendering_info?

@clayjohn
Copy link
Member

I managed to fix this issue following @clayjohn sensei's instruction. Crashes are gone, although I'm not sure If I'm doing it right.

These functions (minus get_video_adapter_type)

Do you mean minus get_rendering_info?

Oops. I didn't mean to include get_rendering_info in the snippet. Neither get_rendering_info nor get_video_adapter_type need the changes as neither make any OpenGL calls

@univeous
Copy link
Contributor Author

I assume it will be harmless if I do the same thing to get_video_adapter_type? It looks more neat that way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants