Unsupported locale causes a crash on Linux

[lapinsami]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

Sunshine (on Arch Linux, KDE) crashes when opening Steam Big Picture mode on the Moonlight app

Expected Behavior

Sunshine does not crash

Additional Context

My LC_TIME is set to en_SE.UTF-8 in the KDE settings. Launching Steam Big picture mode in Moonlight causes Sunshine to crash on the host PC. I think this has something to do with the fact that en_SE.UTF-8 is not a supported locale in glibc (but it is on KDE/Qt).

The locale stuff is probably a problem for KDE devs or whoever, but Sunshine probably also shouldn't crash when ran on KDE with a locale like that.

Sunshine crash + error:

terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
fish: Job 1, 'sunshine' terminated by signal SIGABRT (Abort)

Launching Sunshine with LC_TIME=en_GB.UTF-8 (or any locale supported by glibc) stops the crash from happening

Host Operating System

Linux

Operating System Version

Arch

Architecture

amd64/x86_64

Package

other (self built)

GPU Type

AMD

GPU Model

7800 XT

GPU Driver/Mesa Version

1:26.1.1-2

Capture Method

None

Apps

Log output

Online logs

No response

[ReenigneArcher]

@Kishi85 can we work around this in the tray library?

https://discord.com/channels/804382334370578482/1510602836940165230/1510610134886518946

[lapinsami]

The tray is a completely separate bug. This crash with the locale happens even with the tray disabled, and the tray crash happens even with the locale set manually to en_US.UTF-8.

The tray bug has been reported here #2778 and it is still happening.

[Kishi85]

@Kishi85 can we work around this in the tray library?

https://discord.com/channels/804382334370578482/1510602836940165230/1510610134886518946

Not sure how the tray library would be of help here.

An invalid locale should usually cause a fallback to a defined or the portable "C" or "POSIX"-locale that is available on all POSIX-conformant systems.

[Kishi85]

The tray is a completely separate bug. This crash with the locale happens even with the tray disabled, and the tray crash happens even with the locale set manually to en_US.UTF-8.

The tray bug has been reported here #2778 and it is still happening.

Do you have a stacktrace in your logs? So we can pinpoint which function call is throwing the runtime error?

[ReenigneArcher]

I misunderstood because the discussion started with disabling the tray library

[lapinsami]

Do you have a stacktrace in your logs? So we can pinpoint which function call is throwing the runtime error?

If you can tell me how to get some logs.

sunshine.log has nothing useful in it. These are the last few lines before the crash.

[2026-05-31 19:03:25.545]: Info: // Ignore any errors mentioned above, they are not relevant. //
[2026-05-31 19:03:25.545]: Info: 
[2026-05-31 19:03:25.545]: Info: Found H.264 encoder: h264_vulkan [vulkan]
[2026-05-31 19:03:25.545]: Info: Found AV1 encoder: av1_vulkan [vulkan]

and this is what I get in my terminal when the crash happens

terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
fish: Job 1, 'sunshine' terminated by signal SIGABRT (Abort)

And just to be clear, I am talking about the bug in this thread, not the system tray bug

[Kishi85]

terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
fish: Job 1, 'sunshine' terminated by signal SIGABRT (Abort)

Looking at this in detail it seems to try and fail to create the "C"-Locale which is used for fallback which is a bit weird unless you compile libstd++ without --enable-clocale (taken from https://stackoverflow.com/a/20181564).

Very weird, does this happen with the official Lizardbyte Arch package as well?

[lapinsami]

Tested both the beta and the normal package from the official repo. Both crash with the same error as before.

On Arch Linux, gcc (libstdc++) is compiled with --enable-clocale=gnu.

Now I don't know enough about any of this to really comment, but something somewhere should probably catch that the locale I am using (LC_TIME=en_SE.UTF-8) is complete gibberish from Glibc's point of view (and anything else's that uses the Glibc locale system), and it should fall back to some sane default that doesn't crash the whole app.

I also discovered that the Low Res Desktop option in Moonlight also doesn't work when the locale is set to something non-glibc. But it also doesn't hard crash it just gives an error:

[2026-06-01 00:35:55.221]: Error: Property tree is empty. Probably, control flow got interrupted by an unexpected C++ exception. This is a bug in Sunshine. Moonlight-qt will report Malformed XML (missing root element).

The normal "Desktop" option works without problems no matter the locale.

So I decided to see what the difference is between those "applications" in the Sunshine WebUI, and one difference I found, was that Low Res has some Command Preparations set. So I set one in the normal Desktop "application" as well, and it started giving an error too.

I can also get the normal Desktop "application" to hard crash Sunshine (with the locale::facet::_S_create_c_locale name not valid error) by adding ls (can be anything) as an Undo Command Preparation, and as a Detached Command. Steam has those 2 fields filled in the WebUI as well, so it crashes the same way. With only the Detached Command set, or with all 3 fields (Do, Undo, Detached) set, I get the Property tree is empty error instead.

So probably a bug in how the .json file is parsed or how to commands from there are ran?

[Kishi85]

Now I don't know enough about any of this to really comment, but something somewhere should probably catch that the locale I am using (LC_TIME=en_SE.UTF-8) is complete gibberish from Glibc's point of view (and anything else's that uses the Glibc locale system), and it should fall back to some sane default that doesn't crash the whole app.

locale::facet::_S_create_c_locale name not valid is indicating an error when trying to load that fallback (the C-locale). I've tried to reproduce it with your LC_TIME setting but cannot reproduce the crash so I'm unsure if this is a Sunshine problem.

[Kishi85]

I'm taking a wild guess here but maybe the following patch fixes the issue:

diff --git a/src/main.cpp b/src/main.cpp
index 13df6784..c16c1d3a 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -155,7 +155,13 @@ int main(int argc, char *argv[]) {
 #pragma GCC diagnostic push
 #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   // Use UTF-8 conversion for the default C++ locale (used by boost::log)
-  std::locale::global(std::locale(std::locale(), new std::codecvt_utf8<wchar_t>));
+  try {
+    std::locale::global(std::locale(std::locale(), new std::codecvt_utf8<wchar_t>));
+  } catch (std::runtime_error& e) {
+    BOOST_LOG(warning) << "Falling back to 'C.UTF-8' locale due to runtime error in global locale setup: "sv << e.what();
+    std::locale::global(std::locale(std::locale("C"), new std::codecvt_utf8<wchar_t>));
+  }
+
 #pragma GCC diagnostic pop
 
   mail::man = std::make_shared<safe::mail_raw_t>();