Fix: HLDS Segmentation Fault on Startup (Linux)

The server dies before it ever reaches a map:

./hlds_run: line 456:  1234 Segmentation fault  $HL_CMD
Add "-debug" to the ./hlds_run command line to generate a debug.log

A startup segfault is almost never "HLDS is broken" — it is two pieces of your stack that do not agree, and the trick is to strip the server back to the minimum that still crashes so you know which piece. Work from the outside in.

1. Turn on the crash log

Do exactly what the message says — add -debug:

cd /home/steam/hlds
./hlds_run -debug -game cstrike +map de_dust2 +maxplayers 20 +sv_lan 0

On a crash this writes debug.log in the server directory with a backtrace. The top frames name the library that faulted — engine_i486.so, cs.so, metamod, or an AMXX module. That single line usually tells you the culprit before you change anything.

2. Bisect the stack

Strip to bare HLDS and add layers back. First, disable Metamod/AMXX by pointing liblist.gam back at the game DLL directly (or temporarily rename the metamod entry), and start:

./hlds_run -game cstrike +map de_dust2 +maxplayers 12 +sv_lan 1

• Crashes even with a bare server → the problem is the engine or game DLL (sections 3–4).
• Boots fine bare, crashes with Metamod → the problem is Metamod, a plugin or a module (section 5).

This one test cuts the search space in half and is worth the two minutes.

3. Check the architecture of every binary

The single most common startup segfault is a 64-bit object where a 32-bit one belongs. Everything is 32-bit:

file engine_i486.so cstrike/dlls/cs.so cstrike/addons/metamod/metamod_i386.so

Each must say ELF 32-bit LSB shared object, Intel 80386. Any x86-64 is your bug — you built or downloaded the wrong architecture. A related symptom is wrong ELF class: ELFCLASS64 at load; a hard segfault happens when a mismatched-but-loadable object is called.

4. Mismatched engine and game DLL

A current ReGameDLL against a stale ReHLDS (or a Valve engine) crashes at init because the interfaces do not match. Update both to releases from the same era. Confirm the engine actually is what you think:

./hlds_run -game cstrike +map de_dust2 +sv_lan 1
] rehlds_version

If it segfaults before you can type that, revert to the Valve engine_i486.so.valve.bak you backed up and confirm the bare Valve stack boots — if it does, the ReHLDS/ReGameDLL pairing is the fault.

5. Metamod, plugins and modules

If the bare server boots, re-enable Metamod and check metamod/plugins.ini and AMXX's plugins.ini. A module built for the wrong AMXX or architecture can segfault at load rather than reporting bad load. Comment out third-party modules and plugins, boot clean, then re-add them a few at a time until it crashes — the last batch you added owns the crash. Related loader failures are covered in the bad-load fix.

6. Missing 32-bit libraries

A missing i386 runtime library can crash the loader. Verify dependencies resolve:

ldd engine_i486.so
ldd cstrike/dlls/cs.so

Any not found is a package to install (lib32gcc-s1, lib32stdc++6, libc6:i386). See the base install for the full multiarch setup.

Common errors

• Segmentation fault with a debug.log frame in cs.so — bad or mismatched ReGameDLL, or missing delta.lst. Reinstall the matching build.
• Frame in an AMXX module .so — that module is wrong-architecture or built for another AMXX. Replace it.
• ./hlds_linux: No such file or directory (not a segfault) — the 32-bit loader is missing, not the file. Install i386 libs.
• Crashes only with a full stack, boots bare — bisect Metamod/plugins/modules as in section 5.

Verification

Once it boots, prove the stack is coherent rather than merely surviving:

rehlds_version
regamedll_version
meta list
amxx plugins

All four must answer cleanly with no plugin in bad load or error. Then load a map, let a client connect and play a full round including a map change — a segfault that only appears on connect or map change is a different bug, covered in crash on map change. A clean boot plus a clean full round means the startup fault is genuinely resolved.

Reading debug.log without a debugger

You do not need gdb to get value from debug.log. The file HLDS writes on a crash contains a call stack, and the frames are listed innermost-first — the top few name the shared object that was executing when it died. You are looking for the first line that names one of your stack's libraries:

grep -E "engine_i486|cs\.so|metamod|amxmodx|_amxx" debug.log

If the top frame is in cs.so, suspect ReGameDLL and its delta.lst. If it is metamod or an *_amxx.so/*_i386.so module, suspect that module's architecture or version. If it is engine_i486.so, suspect the engine binary or an engine/game-DLL version mismatch. This does not give you a line number, but it reliably names the guilty component — which is exactly the input the bisection in section 2 needs. Ninety percent of startup segfaults are resolved by pairing that one frame with the architecture check in section 3: the faulting library plus "is it actually 32-bit and are its deps present" answers most cases outright, and the rest fall to bisecting the plugin and module set.