search

alliedmodders / sourcemod

SourceMod - Source Engine Scripting and Administration
http://www.sourcemod.net/
974 stars 422 forks source link

Sourcemod Crashes upon being loaded #2065

Closed BreadDoesStuff closed 11 months ago

BreadDoesStuff commented 11 months ago

Help us help you

Environment

Description

Steps to Reproduce

Logs

crash_20231014203454_2.dmp debug.log

cbpudding commented 11 months ago

I second this. MetaMod seems to run fine by itself but the server crashes when SourceMod is installed. The latest snapshot for MetaMod/SourceMod does not fix the issue for the TF2 dedicated server.

MetaMod SourceMod Result
1.11-1153 N/A Loads
1.11-1153 1.11-6940 Crashes
1.11-1153 1.12-7060 Crashes
1.12-1185 N/A Loads
1.12-1185 1.12-7060 Crashes

GitHub won't let me upload the dump files because it's "not an allowed filetype". Stand by.

https://drive.google.com/drive/folders/1bB18Pk-UPRWbClzBVTbHqeb0hBgtGJ8-?usp=sharing

Gnomesenpai commented 11 months ago

Also experiencing this. Using SM 1.11.0.6923 and MM 1.12.0-dev+1150 are fine though...

Bread are you running within a Docker container? If so who made it?

BreadDoesStuff commented 11 months ago

Also experiencing this. Using SM 1.11.0.6923 and MM 1.12.0-dev+1150 are fine though...

Bread are you running within a Docker container? If so who made it?

Not running within any docker container. Just using a standard launch script for srcds.

Gnomesenpai commented 11 months ago

Also experiencing this. Using SM 1.11.0.6923 and MM 1.12.0-dev+1150 are fine though... Bread are you running within a Docker container? If so who made it?

Not running within any docker container. Just using a standard launch script for srcds.

Been speaking to someone in discord as i've been having the same issue within a docker container, but looks like its a SoureMod issue phew

BreadDoesStuff commented 11 months ago

Just tried the versions that you said were working fine. No crashes at all! Is there a way to prevent sourcemod from automatically updating?

Gnomesenpai commented 11 months ago

Just tried the versions that you said were working fine. No crashes at all! Is there a way to prevent sourcemod from automatically updating?

You can turn it off in /tf/cfg/sourcemod/sourcemod.cfg (if i remember correctly)

Looks like it may be related to this: https://github.com/alliedmodders/sourcemod/issues/2064

sapphonie commented 11 months ago

Just tried the versions that you said were working fine. No crashes at all! Is there a way to prevent sourcemod from automatically updating?

You can turn it off in /tf/cfg/sourcemod/sourcemod.cfg (if i remember correctly)

Looks like it may be related to this: https://github.com/alliedmodders/sourcemod/issues/2064

SourceMod does not auto update its own binaries. It auto updates gamedata, which you almost always want.

I'm not sure that issue is related - MM/SM should just fail to load if you're on an older operating system without a modern glibc.

In the meanwhile, could you install Accelerator, configure it properly with your SteamID, and then post a crash link here?

lxndr commented 11 months ago

Same issue here. It all works fine with Debian 10 + L4D + MM 1.11 + SM 1.11. On Debian 11/12 and Ubuntu 20/22, sourcemod 1.11 crashes. I usually use docker, but I tried VM as well. Here's what I see under gdb.

Screenshot from 2023-10-15 10-35-58

Gnomesenpai commented 11 months ago

My docker containers are based on Debian 11, this should have it in? If not what package is required as this is a breaking change. Accelerator does not load because the server crashes before any plugins load.

lxndr commented 11 months ago

I believe it's a recent regression introduced in build 1.11-git6940. Because for me, the build 1.11-git6939 works fine.

dvander commented 11 months ago

This happened after we upgraded from clang-11 to clang-13. Psychonic managed to figure out that clang-14 fixes it, so we've landed those changes everywhere now. I did some digging tonight into what happened.

This change in clang-12 introduced a regression of some sort: https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6

This caused SourceMod/Metamod:Source to start getting bogus PLT/GOT codegen. Effectively the PIC register was garbage. Why we were even generating GOT/PIC code is strange because we do not use -fPIC on x86.

I'll try bisecting to what fixed this for my own curiosity.

dvander commented 11 months ago

The crash is in PlayerManager::PlayerManager(), trying to call memset(). In clang-12, the call looks like:

   7f970:   e8 fc ff ff ff          call   7f971 <_ZN13PlayerManagerC1Ev+0xc1>

That's a normal, non-PIC relocation. But in clang-13, it looks like:

   7f970:   e8 0b c9 fb ff          call   3c280 <memset@plt>

This is using PIC even though we didn't pass -fPIC. Using PIC is fine, but it requires initializing the PIC register. For some reason, that's not happening. We can see in clang-14 that there's a little prologue to set up PIC:

   7bba4:   83 ec 34                sub    $0x34,%esp
   7bba7:   e8 00 00 00 00          call   7bbac <_ZN13PlayerManagerC1Ev+0xc>
   7bbac:   5b                      pop    %ebx

But in clang-13, this prologue is not getting generated, so the PIC register is trash.

We don't use -fPIC on x86 since historically the performance implications were horrible. It used to prevent EBX from getting used anywhere in the program. These days clang is capable of spilling the PIC register so it's not as bad, so we should probably just bite the bullet and enable -fPIC. Someday.