x86-64 Support

[WinterPhoenix]

This might be a pain in the ass and/or impossible, I know.

My production servers run on the x86-64 beta, which means modules need to be 64-bit to work. Trying to run holylib from Release 0.3 just gives me this:

LD_LIBRARY_PATH=/home/steam/gmod_yuki/bin/linux64:.:bin/linux64:linux64:
/home/steam/gmod_yuki/ghostinj.dll: wrong ELF class: ELFCLASS32
/home/steam/SGS_SRCDS_x64.sh: line 14: 1842163 Segmentation fault      ./bin/linux64/srcds $PARAMS

I humbly request support, if at all possible.

[RaphaelIT7]

This will take a bit, but I think I could get it done in the next few days

[RaphaelIT7]

Finally got the first 64x compile :D https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10219727684

Next step: Symbols.

• [x] Base Symbols
• [x] holylib Symbols
• [x] gameevent Symbols
• [x] serverplugin Symbols
• [ ] sourcetv Symbols
• [x] precachefix Symbols
• [x] stringtable Symbols
• [ ] surffix Symbols
• [ ] pvs Symbols
• [ ] filesystem Symbols
• [x] concommand Symbols
• [x] networking Symbols
• [x] steamworks Symbols
• [x] pas Symbols
• [x] vprof Symbols

Known Issues:

• [x] Stuck when shutting down
• [x] Crash on level shutdown

[RaphaelIT7]

I prioritized the steamworks symbols so that you could use this since you requested those functions.

NOTE: I didn't test it yet on a 64x server.

[WinterPhoenix]

Awesome, thank you! Could you trigger a build of 64-bit ghostinj for testing as well?

[RaphaelIT7]

https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10221980658

[WinterPhoenix]

Using these builds:

• Ghostinj: https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10221980658
• HolyLib: https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10221980750

Okay, first issue is it tries to load _linux.so instead of _linux64.so:

--- Holylib Loading ---
Failed to open gmsv_holylib_linux.so (garrysmod/lua/bin/gmsv_holylib_linux.so: cannot open shared object file: No suc
h file or directory)
Failed to find holylib entry point (/home/steam/gmod_yuki/ghostinj.dll: undefined symbol: HolyLib_PreLoad)
--- Holylib loaded ---

Also funny that it says "loaded" when it didn't.

If I rename it, it starts to load stuff but I get a segfault:

Server will auto-restart if there is a crash.
LD_LIBRARY_PATH=/home/steam/gmod_yuki/bin/linux64:.:bin/linux64:linux64:
--- Holylib Loading ---
Registered module holylib (Enabled: true)
Registered module gameevent (Enabled: true)
Registered module serverplugin (Enabled: true)
Registered module sourcetv (Enabled: true)
Registered module threadpoolfix (Enabled: true)
Registered module stringtable (Enabled: true)
Registered module precachefix (Enabled: true)
Registered module pvs (Enabled: true)
Registered module surffix (Enabled: true)
Registered module filesystem (Enabled: true)
Registered module util (Enabled: true)
Registered module concommand (Enabled: true)
Registered module vprof (Enabled: true)
Registered module cvars (Enabled: true)
Registered module bitbuf (Enabled: true)
Registered module networking (Enabled: true)
Registered module steamworks (Enabled: true)
Registered module pas (Enabled: true)
/home/steam/SGS_SRCDS_x64.sh: line 14: 3687205 Segmentation fault      ./bin/linux64/srcds $PARAMS

Here's the DMP for that: 5b5d94d7-01b1-461a-f8ea94b9-fe9b112d.zip

[RaphaelIT7]

So you can now start but level shutdown will cause a crash or it still be stuck when shutting down and I have no idea why :/ I probably have to ask rubat later to fix this crash

[WinterPhoenix]

Using build: https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10254871829

Still segfaults on startup for me. It gets further though.

LD_LIBRARY_PATH=/home/steam/gmod_yuki/bin/linux64:.:bin/linux64:linux64:
--- Holylib Loading ---
Registered module holylib         (Enabled: true,  Compatible: true )
Registered module gameevent       (Enabled: false, Compatible: false)
Registered module serverplugin    (Enabled: true,  Compatible: true )
Registered module sourcetv        (Enabled: false, Compatible: false)
Registered module threadpoolfix   (Enabled: false, Compatible: false)
Registered module stringtable     (Enabled: true,  Compatible: true )
Registered module precachefix     (Enabled: false, Compatible: false)
Registered module pvs             (Enabled: false, Compatible: false)
Registered module surffix         (Enabled: false, Compatible: false)
Registered module filesystem      (Enabled: false, Compatible: false)
Registered module util            (Enabled: true,  Compatible: true )
Registered module concommand      (Enabled: true,  Compatible: true )
Registered module vprof           (Enabled: false, Compatible: false)
Registered module cvars           (Enabled: true,  Compatible: true )
Registered module bitbuf          (Enabled: true,  Compatible: true )
Registered module networking      (Enabled: true,  Compatible: true )
Registered module steamworks      (Enabled: true,  Compatible: true )
Registered module pas             (Enabled: false, Compatible: false)
Registered module bass            (Enabled: true,  Compatible: true )
--- Holylib loaded ---

...

--- HolyLib Plugin loading ---
[holylib] Failed to get function InitLuaClasses!
[holylib] Failed to get function Get_Player!
[holylib] Failed to get function Push_Entity!
[holylib] Failed to get function Get_Entity!
[holylib] Failed to get function CServerGameDLL::ShouldHideServer!
[holylib] Failed to get function CPlugin::Load!
[holylib] Failed to get function ConCommand_IsBlocked!
[holylib] Failed to get function CSteam3Server::OnLoggedOff!
[holylib] Failed to get function CSteam3Server::OnLogonSuccess!
WARNING: unable to link fs_warning_level and fs_warning_level because one or more is a ConCommand.
WARNING: unable to link fs_printopenfiles and fs_printopenfiles because one or more is a ConCommand.
WARNING: unable to link path and path because one or more is a ConCommand.
--- HolyLib Plugin finished loading ---

...

Making workshop gamemode available for client download
Executing dedicated server config file server.cfg
Using map cycle file cfg/mapcycle.txt.
/home/steam/SGS_SRCDS_x64.sh: line 14: 1902036 Segmentation fault      ./bin/linux64/srcds $PARAMS

DMP: bccc830b-a605-471f-f2b2a59c-70fdb44e.zip

[RaphaelIT7]

I'll look into it today

[RaphaelIT7]

The crash on startup is fixed and I also fixed the symbol for InitLuaClasses so that the Lua API will be available as soon as possible / it won't try to use the fallback method

[RaphaelIT7]

The issue which causes the crash on level shutdown is definetly caused by ConVars :/ and being stuck when completly shutting down is caused by the -usegh argument / the ghostinj dll but it doesn't seem to be caused by the dll directly.

To fix the ConVar crash for now, I won't be registering them so you can't directly modify them. And to solve the ghostinj hang, you can just not use it / it won't be required for 64x.
It is only really used for 32x to fix the threadpool issue

[WinterPhoenix]

Okay! Getting a lot closer here.

Using Build: https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10486233377

The server no longer segfaults/hangs on initial startup/shutdown. However, while using both HolyLib and gmod-chttp, if I call steamworks.Shutdown() at all, even if I call steamworks.Activate() after, the server will segfault at the next HTTP call. This behavior persists across changelevels as well.

Not sure if it's a problem with CHTTP or HolyLib. Works fine if I use HolyLib without CHTTP.

DMP: fa180dd4-1ed0-4cd2-0f5299ac-d8af1948.zip

[RaphaelIT7]

It could be that I have an invalid symbol somewhere

[RaphaelIT7]

If I see this correctly, when calling Shutdown, it will crash in the next few frames when without chttp. So it could be that I got the symbol of the wrong function or the engine just can't handle it for some reason

Edit: Just checked the Symbol and it seems to be right :|

[WinterPhoenix]

Using Build: https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10580920040

Okay. I understand a little better what's going on, but I still don't have a full explanation. steamworks.Shutdown() will cause a segfault in my gamemode with CHTTP...but only if something tries to use the ISteamHTTP function.

http.Fetch and http.Post have a localized HTTP function by default, which means calls to those were using ISteamHTTP even though I had HTTP = CHTTP elsewhere.

I can effectively avoid the segfault by just overriding those to use CHTTP as well. It doesn't address whatever the root cause is, but it's a really specific set of circumstances involving the Lua state it seems...

Also, steamworks.ForceActivate() doesn't seem to work at all:

> print(steamworks.ForceActivate())...

[ERROR] lua_run:1: Failed to load SV_InitGameServerSteam!

  1. ForceActivate - [C]:-1
   2. unknown - lua_run:1

And pas.TestPAS() causes a segfault even without any other modules loaded, with the vanilla base gamemode:

> print(pas.TestPAS(Vector(0, 0, 128), Vector(0, 0, 256)))...
/home/steam/SGS_SRCDS_x64.sh: line 14: 860804 Segmentation fault      ./bin/linux64/srcds $PARAMS

DMP: f8ce69b2-1ac6-4c0f-18fde3bd-963bc2cd.zip

[RaphaelIT7]

steamworks.ForceActivate didn't support 64x at that point but It should now.

[WinterPhoenix]

Using Build: https://github.com/RaphaelIT7/gmod-holylib/actions/runs/10682631128

So we have a new issue now, with Player:StripWeapon. In my gamemode it causes a segfault. In the vanilla base gamemode, it causes Lua Error: C++ exception. I still don't know why some Lua Errors originating from the C++ side cause a segfault in my gamemode.

Code to reproduce:

lua_run Entity(1):Give("weapon_pistol")
lua_run Entity(1):StripWeapon("weapon_pistol")

No issue when not loading HolyLib.

DMP: b6bd21e8-6d4b-426c-fbf2aabb-970a2f95.zip

[RaphaelIT7]

try it with vprof off. -holylib_enable_vprof 0 on 64x vprof is I think completly disabled and I think I try to use it which breaks it

[WinterPhoenix]

that fixed it lol

[RaphaelIT7]

I'll be fixing a bf_write function and then I'm gonna try to fix the pas crash Edit: I also added a threadpoolfix for the 64x since it seems like it's broken again in gmod (See: https://github.com/Facepunch/garrysmod-issues/issues/5310)

Edit 2: I'll fix pas tomorrow since I don't habe the time for it rn

[RaphaelIT7]

It's a pain to get pas working on 64x :/ I can't properly get the g_BSPData and even when I load it manually I still get invalid data since something on 64x is different :< It'll probably take a good few days or even weeks. (Out of curiosity, do you use 64x for servers and if so what's your decision behind it?)

[WinterPhoenix]

I run x86-64 on my production servers. It's for a few reasons, but mainly it's because if 64-bit is the future of GMod, which I will continue to act like it is regardless of Facepunch's boneheaded decisions, somebody has to test it.

Like, it's ridiculous. It's current year, nothing is 32-bit only anymore, and whole operating systems are dropping/have dropped support for it (macOS is still listed as supported on the store page, even!).

TF2's source branch is fairly close to GMod and they could take a look at that if they really are at a total loss for how to continue Willox's work on x86-64.

[RaphaelIT7]

I personally would just hope that if they switch to 64x that they still continue to support 32x dedicated servers. 64x is a huge pain for projects like this one, and It can also be a pain to maintain them, so as long as 64x server don't have debug symbols or better support like new engine interfaces / functions I wouldn't want this switch to happen if it means that 32x Servers won't be supported anymore.  But 64x itself would open some interesting possibilities.

Edit: Anyways, I'll be trying tomorrow again with pas

[RaphaelIT7]

A while ago I got pas working on 64x. Since the last few modules now missing are a bit harder to implement and will take longer, is there one that should be prioritized?

[WinterPhoenix]

Nice! Well the two heavy hitters for me are Steamworks and PAS, so as long as those two work I’m happy.

Maybe reviving/making functional vprof on x64 if possible?

[RaphaelIT7]

Vprof in general on 64x seems weird. I don't know why it even crashes but it seems like In gmod VPROF_LEVEL is set to 0 which causes most vprof calls in the engine to not even be recorded / vprof is simply disabled for almost every thing (thats why vprof_generate_report is so empty). Thats just for Gmod's vprof calls. (Could probably ask Rubat about it) HolyLibs calls crashing are still a thing that I can't figure out yet. I'll look into it tomorrow again but from what I can tell it could be that I got a symbol wrong

[RaphaelIT7]

vprof finally works on 64x. I had an invalid symbol there, and the sdk itself was broken because an unsigned int was compared against a unsigned long. Maybe that's also why vprof itself is broken. My original theory with VPROF_LEVEL could be wrong, so I would guess gmod has the same issue. https://github.com/RaphaelIT7/sourcesdk-minimal/commit/a23b6e8f2e38f6605f8f8106107f5b9601ed5ec7