FreeImage DllNotFoundException on Linux Headless

[PointerOffset]

Describe the bug?

When attempting to start a Headless on a Linux Docker Container it immediately crashes as it's unable to load FreeImage. The container starts up with a fresh install of Resonite every time so this appears to be the current state of a fresh install for Headless servers.

This bug does not occur on a Windows Headless.

To Reproduce

1. Install Resonite on Linux via SteamCMD:
   steamcmd.sh +force_install_dir /resonite +app_license_request 2519830 +app_update 2519830 -beta headless validate -betapassword [HEADLESS_BETA_PASSWORD] +quit

2. Run Headless Client:

cd /resonite/Headless
exec mono Resonite.exe

Expected behavior

Headless client will start up to NO WORLD or configured worlds from Config.json

Screenshots

No response

Resonite Version Number

Headless 2024.1.24.840

What Platforms does this occur on?

Linux

What headset if any do you use?

No response

Log Files

18:22:22.753	AppPath: /home/resonite/resonite-headless/Headless
DataPath: /Data
CachePath: /Cache
18:22:22.760	Initializing App: Beta 2024.1.24.840
OS Platform: Unix 5.15.0.91 (X64)
Platform: Linux
HeadDevice: Headless
IsAOT: False
OS: Debian GNU/Linux
CPU: AMD Ryzen 7 3800X 8-Core Processor
GPU: UNKNOWN
PhysicalCores: 8
MemoryBytes: 62.72 GB
VRAMBytes: -1.00 B
MaxTextureSize: 16384
IsGPUTexturePOTByteAligned: True
UsingLinearSpace: False
XR Device Name: 
XR Device Model: 
StereoRenderingMode: 
Max GC Generation: 1, IsLittleEndian: True
System.Numerics.Vectors HW accelerated: True, Vector<float>.Count: 4
Brotli native encoding/decoding supported: True
18:22:22.761	Supported Texture Formats: Unknown, Alpha8, R8, RGB24, ARGB32, RGBA32, BGRA32, RGB565, RGBAHalf, ARGBHalf, RHalf, RGHalf, RGBAFloat, ARGBFloat, RFloat, RGFloat, BC1, BC2, BC3, BC4, BC5, BC6H, BC7, ETC2_RGB, ETC2_RGBA1, ETC2_RGBA8, ASTC_4x4, ASTC_5x5, ASTC_6x6, ASTC_8x8, ASTC_10x10, ASTC_12x12
18:22:22.762	Processing startup commands...
18:22:22.765	Scanning locales...
18:22:22.767	Available locales: cs, de, en, en-gb, eo, es, et, fi, fr, is, ja, ko, nl, no, pl, pt-br, ru, sv, tr, zh-cn, zh-tw
18:22:22.775	Loading Config.json...
18:22:22.776	Computing compatibility hash...
18:22:22.776	Compatibility Hash: cNoRMlv21dYGAXEIHoIY+w==
18:22:22.777	Initializing FrooxEngine...
18:22:23.589	Exception initializing FrooxEngine:
System.TypeInitializationException: The type initializer for 'Elements.Assets.TextureDecoder' threw an exception. ---> System.TypeInitializationException: The type initializer for 'FreeImageAPI.Plugins.PluginRepository' threw an exception. ---> System.DllNotFoundException: FreeImage assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) FreeImageAPI.FreeImage.GetFIFCount()
  at FreeImageAPI.Plugins.PluginRepository..cctor () [0x00000] in <c0470cb89fa84a59aa5508a0fecfc864>:0 
   --- End of inner exception stack trace ---
  at Elements.Assets.TextureDecoder..cctor () [0x0001b] in <95d3de0e945a46bbb0eadf553a9c3449>:0 
   --- End of inner exception stack trace ---
  at FrooxEngine.LibraryInitializer.Initialize (FrooxEngine.Engine engine) [0x0006e] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.EngineInitializer.InitializeFrooxEngine (FrooxEngine.Engine engine) [0x0005f] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.Engine.InitializeFrooxEngine () [0x00086] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 

  at System.Environment.get_StackTrace () [0x00000] in <de882a77e7c14f8ba5d298093dde82b2>:0 
  at Elements.Core.UniLog.Error (System.String message, System.Boolean stackTrace) [0x00000] in <10b2b681c3964341948f01c8c5862fc4>:0 
  at FrooxEngine.Engine.InitializeFrooxEngine () [0x00000] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine] (TStateMachine& stateMachine) [0x00000] in <de882a77e7c14f8ba5d298093dde82b2>:0 
  at FrooxEngine.Engine.InitializeFrooxEngine () [0x00000] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.Engine.Initialize (System.String appPath, FrooxEngine.LaunchOptions options, FrooxEngine.ISystemInfo systemInfo, FrooxEngine.IInternalResource resources, FrooxEngine.IEngineInitProgress progress) [0x00000] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine] (TStateMachine& stateMachine) [0x00000] in <de882a77e7c14f8ba5d298093dde82b2>:0 
  at FrooxEngine.Engine.Initialize (System.String appPath, FrooxEngine.LaunchOptions options, FrooxEngine.ISystemInfo systemInfo, FrooxEngine.IInternalResource resources, FrooxEngine.IEngineInitProgress progress) [0x00000] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.StandaloneFrooxEngineRunner.Initialize (FrooxEngine.LaunchOptions options) [0x00000] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine] (TStateMachine& stateMachine) [0x00000] in <de882a77e7c14f8ba5d298093dde82b2>:0 
  at FrooxEngine.StandaloneFrooxEngineRunner.Initialize (FrooxEngine.LaunchOptions options) [0x00000] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.Headless.Program.Main (System.String[] args) [0x00000] in <17723fbb08634afe83395df3b3d06ab4>:0 
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine] (TStateMachine& stateMachine) [0x00000] in <de882a77e7c14f8ba5d298093dde82b2>:0 
  at FrooxEngine.Headless.Program.Main (System.String[] args) [0x00000] in <17723fbb08634afe83395df3b3d06ab4>:0 
  at FrooxEngine.Headless.Program.<Main> (System.String[] args) [0x00000] in <17723fbb08634afe83395df3b3d06ab4>:0 
18:22:23.590	Unhandled Exception:

System.TypeInitializationException: The type initializer for 'Elements.Assets.TextureDecoder' threw an exception. ---> System.TypeInitializationException: The type initializer for 'FreeImageAPI.Plugins.PluginRepository' threw an exception. ---> System.DllNotFoundException: FreeImage assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) FreeImageAPI.FreeImage.GetFIFCount()
  at FreeImageAPI.Plugins.PluginRepository..cctor () [0x00000] in <c0470cb89fa84a59aa5508a0fecfc864>:0 
   --- End of inner exception stack trace ---
  at Elements.Assets.TextureDecoder..cctor () [0x0001b] in <95d3de0e945a46bbb0eadf553a9c3449>:0 
   --- End of inner exception stack trace ---
  at FrooxEngine.LibraryInitializer.Initialize (FrooxEngine.Engine engine) [0x0006e] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.EngineInitializer.InitializeFrooxEngine (FrooxEngine.Engine engine) [0x0005f] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.Engine.InitializeFrooxEngine () [0x000ad] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.Engine.Initialize (System.String appPath, FrooxEngine.LaunchOptions options, FrooxEngine.ISystemInfo systemInfo, FrooxEngine.IInternalResource resources, FrooxEngine.IEngineInitProgress progress) [0x00674] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.StandaloneFrooxEngineRunner.Initialize (FrooxEngine.LaunchOptions options) [0x000e7] in <b7b3bb52ad8949c5bfe93ba6854f8e55>:0 
  at FrooxEngine.Headless.Program.Main (System.String[] args) [0x00396] in <17723fbb08634afe83395df3b3d06ab4>:0 
  at FrooxEngine.Headless.Program.<Main> (System.String[] args) [0x0000c] in <17723fbb08634afe83395df3b3d06ab4>:0 

Additional Context

No response

Reporters

Github: @PointerOffset, Discord: @spexcat

[shiftyscales]

Sounds to be a regression from the most recent build in which the FreeImage library was updated, @Frooxius.

[sveken]

Getting this issue as well, and my container doesn't reinstall completely fresh on each start.
c2f208b72976 - 2024.1.24.840 - 2024-01-25 08_29_00.log

[skywindkitsune]

getting the same with our servers, did we mislocate the file again?

[ohzee00]

There is a latest release with the freeimage dll, even for linux. Assuming it is built correctly it could be a drag and drop solution til things are properly patched: https://github.com/Yellow-Dog-Man/FreeImage/releases/tag/3.18.0-ydm-0.1.5

[code807]

I can confirm the manual solution works until there is a patch. Adding the appropriate lib file to the Headless directory fixes the crash.

[sveken]

I have tried multiple times to drag the file over into the "Headless" folder and the headless container still doesnt wan't to start with the freeimage error. Not sure what im doing wrong.

[ohzee00]

While I don't want to bother when the issue is already known, I do want to stress this is affecting most headlesses that are containerized and can't as easily patch in a new DLL.
Funny enough we learned there is a steam API limit we hit with how much a friend's headless has tried to restart and update due to crashing on launch due to this issue.

[Frooxius]

I'm a bit confused on what's happening here. I just checked the files and the libFreeImage.so is present there. It looks present on the depot as well. Its hash matches the one from https://github.com/Yellow-Dog-Man/FreeImage/releases/tag/3.18.0-ydm-0.1.5

Is the file missing in your install completely? Or do you need a different version than that one?

[crystalclaw]

Disclaimer: I'm not sure if I fully understand what's going on here, but I'll give what I can

I don't know if libFreeImage.so is missing, but FreeImage.dll is definitely missing. I don't know if it's necessary to be present on headlesses but it is present on the client install, and from some rough explanation of how this works it's my understanding that's also necessary there?

I didn't dig into it too much because we were trying to get a session up, but if this isn't fixed by the time I get off work I'd be happy to dig into it a bit deeper and experiment

[Nutcake]

FreeImageNET.dll does exist in the headless install, however FreeImage.dll does not. Are we sure the naming scheme is correct for all of these and Resonite is looking in the right places?

[Frooxius]

FreeImage.dll is not supposed to be in the Linux headless - that's the Windows x64 native library - so that is correct behavior.

libFreeImage.so is the Linux native version of the same library. It looks like it is there.

What I am confused by is that above there are claims that copying it from the repo fixes this problem - but I don't see how is this possible, since it's already there?

[Nutcake]

Looking at the mono debug log when running with MONO_LOG_LEVEL=debug, this line sticks out to me when trying to load libFreeImage.so:

Mono: DllImport error loading library '/home/steam/resonite-headless/Headless/libFreeImage.so': '/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.29' not found (required by /home/steam/resonite-headless/Headless/libFreeImage.so)'.

Looking at the glibc versions available in libstdc++ indeed shows that the required version is missing:

steam@02d92d7f8ee1:~/resonite-headless/Tools$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH

[Frooxius]

It looks like the newer version might require a newer version of glibc. This might be the result of the cloud compilation process differences.

I've opened an issue here: Yellow-Dog-Man/FreeImage#10

[Nutcake]

For the time being for anyone needing a workaround, here is a build of FreeImage created with Debian 10, the minimum required GLIBC version is 3.4.21. Replacing the existing libFreeImage.so in Resonite/Headless/ should resolve the issue.

[Nutcake]

I've created a pull request on FreeImage that should fix Linux build compatibility by compiling inside a Debian buster container.
Yellow-Dog-Man/FreeImage#12

[sveken]

That makes sense and why Bredos Pterodactyl image still works as it uses deb 12. Recompiling it for an older version would be great for now but i think long term its best to get the docker container we are using updated to a more recent base.

I have tried https://github.com/ijs01140/resonite-headless Version of the docker container as i understand it was on bookworm. However same error comes up

[code807]

@Frooxius When I tested this on my headless, I had limited info and the test was a bit rushed. I did not actually confirm that mine crashed without the library before adding it. I was told by another user that the default behavior was a crash, and asked to update, manually add the library, and see if there are any issues. There was no crash so I reported it as a working solution. It is possible my headless might have booted without any issues without any manual library changes.

[Frooxius]

Merged this in 2024.1.26.617, should work better now. Thanks for the help!

[sveken]

Yup all fixed. Thank you