Godot C# beta native Linux build crashes when launched through Steam

[weak lily]

Hello engineers! I'm not entirely sure if this is the right place to ask, let me know if there's a more appropriate forum.

We've recently started using Sentry and are loving all the functionality, and the Godot C# integration/beta branch couldn't have come at at a better time for us.

Everything is working perfectly when we export the game for Windows, publish to Steam and launch it through the Steam library.
We noticed however that for the native Linux export there seems to be an issue, as it crashes instantly when launched through the Steam library.

Interestingly I can browse to the local files that Steam has downloaded and run the same binary that the launcher would, and it runs without any issues.

I've confirmed that this is caused by Sentry by removing the plugin (and calling code) and re-publishing the build as I normally would, resulting in a working native Linux build. I have reproduced this on both a Fedora desktop install and a default Steamdeck.

I'm unsure if this is a direct problem with Sentry or how Steam handles their linux runtimes, so not even sure if this is just a me issue, or if this is on Setnry's end - or if it's more how Godot's dotnet 8 targeting interacts with Sentry's dotnet 10. I tried a few adjustments to our .csproj, disabling the Steam overlay on launch, as well as various compatibility modes to see if we can rectify this, but haven't had any success. Even running the Windows build through the Proton compatibility layer breaks when run on Linux.

I've attached the crash details and below the brief Godot logs of the instant crash:

ERROR: .NET: Failed to get GodotPlugins initialization function pointer
   at: initialize_hostfxr_and_godot_plugins (modules/mono/mono_gd/gd_mono.cpp:484)
ERROR: Parameter "godot_plugins_initialize" is null.
   at: initialize (modules/mono/mono_gd/gd_mono.cpp:653)

I suspect this is more of an interaction between Steam/Godot/Sentry/default settings than an actual Sentry bug, but given this would be a pretty standard use case I thought I'd raise it here.

[queen ember]

Hello, Michael. I'll see if I can reproduce it locally. Which SDK version are you using?

[weak lily]

The build we published through Steam was 2.0.0-beta.0, however I also tried updating it to 2.0.0-beta.1, ran a local build (simply drag-dropped the built files into the Steam install folder) and still saw it happening

[queen ember]

is it scout or sniper runtime?

[weak lily]

I've tried the scout runtime through the compatibility settings, but I'm unsure which one it uses if none is selected by default

[queen ember]

It's probably not the issue here, but scout rutnime is not supported currently due to libcurl incompatibilities

https://github.com/getsentry/sentry-godot/issues/613

Valve recommends sniper for new games

[weak lily]

Ah interesting, I just read up on it and it does look like they still default back to scout, let me set it up on Steamworks, one sec

I've configured it to use sniper, but without any compatibility settings enabled it still crashes instantly.

Interestingly sniper does not show up in the compatibility options

I don't think it's the issue, but we are using Steamworks.NET.AnyCPU as a nuget package (it's built against the current 1.64 Steamworks SDK)
https://github.com/Akarinnnnn/Steamworks.NET.AnyCPU

[queen ember]

If you publish as scout, it only shows compatibility and scout unfortunately

For some reason, users cant override and select sniper in that case

[weak lily]

Hm, but changing the runtime in the installation settings should still update it though, right?

As in, in Steamworks

[queen ember]

If you see scout in the compatibility settings, then it probably didn't

I tried locally with steam containers (added as a non-steam game)
Crashes in scout, works in sniper
So maybe it is runtime issue? I'm building from source on Arch Linux but it should be similar story with the beta.1 . I'll check just in case.

[weak lily]

Ah all good, sorry it is now running Sniper and works 🥳

(I got slightly confused between our actual app and the playtest app - changed settings on one and ran the other)

[queen ember]

Oh great! Love hearing that!

[weak lily]

Amazing work, thanks for helping us getting that sorted! Again, loving the product, we're about to start running online playtest sessions so it'll be very useful!

We've only done in-person ones so far and having to pull the log files off of each device was painful 😄

[queen ember]

Yeah, that can be frustrating for playtesting. Check the logs feature if you haven't already, it's currently opt-in - you'll need to flick some toggles in project settings.

[weak lily]

Already discovered and running - I was a bit confused around whether I should use logs or breadcrumbs but opted for logs 🙂

[queen ember]

Breadcrumbs predate logs, they overlap a bit in functionality. Breadcrumbs are added to events (max 100 in a circular buffer), so they are only send when error occurs. Logs have a dedicated batcher that collects and sends them independently from events in a background thread.

[weak lily]

Yeah, I thought it might be useful to add both, the phrasing on the documentation page kind of made me feel like I should be using logs instead of breadcrumbs, rather than alongside them

[queen ember]

Functionally, logs are similar to breadcrumbs but more and better. I might not be the best person to explain them 😅

[weak lily]

All good, thank you again for solving this - really glad to see some c# Godot love 🙂