Tixx
9bc22de9b0
1. Issue: Broken QueueThread joining logic which relies on thread being
`joinable` which is unrelated to doing `join`, leading to the case where
the network thread crashes when it reaches the end of scope, due to a
`std::terminate` in the dtor of `std::thread` (throws on destruction
when unjoined). Fix: Using `std::jthread` which uses RAII to join on
destruction.
2. Issue: Slow hardware or overloaded server can cause a client to
disconnect and socket to close before `TNetwork::DisconnectClient` is
called, but `IsDisconnected()` will still be false. In this case,
`.remote_endpoint()` can fail, which throws an exception, which is not
caught and thus `std::terminate`s the server. I observed this, even
though it was only in extremely contrived scenarios, it still happened
and crashed the server. Fix: Wrapping the whole block in a try/catch.
Alternate fix would have been to pass an `error_code` but the result is
the same. This fix is not quite enough though, a later fix resolves the
remaining issue that this causes the `mClientMap` to ignore the
disconnection. Also, all paths that do `if (c.IsDisconnected())` will
fail to decrement the `mClientMap`, which isn't always the right
behavior afaik. Fixed in another fix though.
3. Issue: Connection limiting ("DDoS protection") is broken as
exceptions cause it to not decrement (and slowly fill up the
`mClientMap`) in special cases. Mutexes are locked and unlocked manually
which can (and will) lead to cases where the mutex is locked, an
exception is thrown in the subsequent line (`address().to_string()` can
throw, same with `.remote_endpoint()`, both of which are being called in
the locked context without RAII unlocking). Fix: Replace manual map and
mutex handling with a new class, `TConnectionLimiter`, and an associated
"Guard" object `TConnectionLimiter::TGuard` which uses RAII to correctly
keep track of IP-and-connection-count associations, the way the previous
code was trying to do. This works across exceptions and other weird
issues. Each connection's main thread now owns a guard, which, on
destruction, decrements the counter. This way both the per-IP limits as
well as the global limits are enforced. Also added some stats about this
to the `status` command to ensure that server owners can observe this in
action.
4. Issue: `.address().to_string()` can throw and is called even if
`accept` failed, in `TNetwork::TCPServerMain`'s accept loop. I didn't
observe this and it didn't cause crashes, but I was touching that part
anyway. Fix: Explicitly handle the error case first, then get the IP,
etc.
5. Issue: `ReadWithTimeout` spawned a new async context for each read,
and then ran that context's event loop in a new thread. This means that,
not only did every one of those reads SPAWN A THREAD(!!!), it also
started an io context, which gets an fd, so this made DDoS arguably more
effective, not less.
6. Issue: Client disconnect can race due to being done on multiple
threads (TOCTOU bug). For example `Looper` and a normal disconnect call
can happen at the same time, because they check for `is_open` which can
be true, and then change to false right after the check, causing a
segfault in asio internals. Fix: Added an atomic compare-and-swap (CAS)
mechanic that acts like a lock for the socket disconnect/close, and
adjusted other places that checked `is_open`.
8. Issue: Lua panic calls the panic handler, and if the error supplied
in the panic is not a string, or is otherwise invalid, it will trigger
another panic within the panic handler. This continues and eventually
crashes the program in one of many fun ways. Fix: Use raw lua functions
to check if the top of the stack is a string, and only then print it,
otherwise print that there was a panic and leave it at that.
9. Issue: `error()` crashes the server, due to `sol::error`'s
constructor expecting a `std::string` (`lua_tostring` or `__tostring`
meta method), which doesn't exist if the error is, for example, `nil`. I
reported this to sol2, but it might be an issue only in this older
version we're using. Fix: Fixed as part of the next issue:
10. Issue: `TLuaResult` was used/accessed from multiple threads,
including `sol::object` accessed from multiple threads. This lead to
each access of a `TLuaResult::Result` accessing the Lua stack of that
state (from outside that state's thread, which is unsafe). This
consistently lead to issues and sometimes crashes. Fix: `TLuaResult` now
always marshals results into a detached result variant. This allocates,
but this is unlikely to impact the hot paths, as most results will be
empty or have primitive types. **UPDATE 2026-04-29:** This fix caused
some other issues, so I added a result type that has no result value,
only a status. That seems to help.
11. Issue: HTTP retains a curl handle per thread and never cleans them
up. With one new thread per client, each doing an auth request at least,
this quickly exhausts all file descriptors. This manifests itself as
**dns resolutions failing**, as the server fails to open a socket to
send a DNS query. Fix: The HTTP code now retains a pool of reusable
handles, which clean up automatically via RAII. I tried to build this in
a way that doesn't modify the code too much, so I kept it global and
static.
12. Issue: Crash when accessing an expired `std::weak_ptr<TClient>`.
This can happen when we check for `.expired()`, and then `.lock()`,
which is, of course, another TOCTOU (time of check vs time of use) bug.
What youre SUPPOSED to do instead, is locking, which always returns a
`std::shared_ptr<>`, and then check `std::shared_ptr<>::operator bool`.
An expired `std::weak_ptr` will return a default-constructed
`std::shared_ptr`, which evaluates to `false` when converted to `bool`.
Fix: Replaced all uses of `.expired()` and other such checks with the
correct pattern. This was a lot of search and manual replace :D.
I used LLMs to help with writing unit-tests, but those do not compile
into the final executable anyway. If this is undesired, I'm happy to
remove that code.
---
By creating this pull request, I understand that code that is AI
generated or otherwise automatically generated may be rejected without
further discussion.
I declare that I fully understand all code I pushed into this PR, and
wrote all this code myself and own the rights to this code.
BeamMP-Server
This is the server for the multiplayer mod BeamMP for the game BeamNG.drive. The server is the point through which all clients communicate. You can write Lua mods for the server, there are detailed instructions on the BeamMP Wiki.
For Linux, you need the runtime dependencies, which are listed below under Runtime Dependencies
Support + Contact
Feel free to ask any questions via the following channels:
- Discord: click for invite
- BeamMP Forum: BeamMP Forum Support
Minimum Requirements
These values are guesstimated and are subject to change with each release.
- RAM: 30-100 MiB usable (not counting OS overhead)
- CPU: >1GHz, preferably multicore
- OS: Windows, Linux (theoretically any POSIX)
- GPU: None
- HDD: 10 MiB + Mods/Plugins
- Bandwidth: 5-10 Mb/s upload
Contributing
TLDR; Issues with the "help wanted" or "good first issue" label or with nobody assigned.
To contribute, look at the active issues. Any issues that have the "help wanted" label or don't have anyone assigned are good tasks to take on. You can either contribute by programming or by testing and adding more info and ideas.
Fork this repository, make a new branch for your feature, implement your feature or fix, and then create a pull-request here. Even incomplete features and fixes can be pull-requested.
If you need support with understanding the codebase, please write us in the Discord. You'll need to be proficient in modern C++.
About Building from Source
We only allow building unmodified (original) source code for public use. master is considered unstable and we will not provide technical support if such a build doesn't work, so always build from a tag. You can checkout a tag with git checkout tags/TAGNAME, where TAGNAME is the tag, for example v3.4.1. See the tags for possible versions/tags, as well as the releases to check which version is marked as a release/prerelease. We recommend using the latest release.
Supported Operating Systems
The code itself supports (latest stable) Linux, Windows and FreeBSD. In terms of actual build support, for now we usually only distribute Windows binaries and Linux. For any other distro or OS, you just have to find the same libraries listed in Runtime Dependencies further down the page, and it should build fine.
Recommended compilers: MSVC, GCC, CLANG.
You can find precompiled binaries under Releases.
Build Instructions
On Linux, you need some dependencies to build the server (on Windows, you don't):
liblua5.3-dev curl zip unzip tar cmake make git g++
You can install these with your distribution's package manager. You will need sudo or need root for ONLY this step.
The names of each package may change depending on your platform.
If you are building for ARM (like aarch64), you need to run export VCPKG_FORCE_SYSTEM_BINARIES=1 before the following commands.
You can build on Windows, Linux or other platforms by following these steps:
- Check out the repository with git:
git clone --recursive https://github.com/BeamMP/BeamMP-Server. - Go into the directory
cd BeamMP-Server. - Specify the server version to build by checking out a tag:
git checkout tags/v3.4.1- Possible versions/tags - Run CMake
cmake -S . -B bin -DCMAKE_BUILD_TYPE=Release- this can take a few minutes and may take a lot of disk space and bandwidth. - Build via
cmake --build bin --parallel --config Release -t BeamMP-Server. - Your executable can be found in
bin/.
When you make changes to the code, you only have to run step 4 again.
Building for FreeBSD
Building is only supported for major release branches of FreeBSD that are currently not EOL. The build process is the same as on Linux, although build dependencies can be universally installed from ports via pkg:
pkg install git cmake-core zip bash devel/ninja devel/pkgconf lua53
After installing the necessary build dependencies, follow the Linux build instructions beginning from step 3. Beware that running the initial cmake command will compile vcpkg from source, as vcpkg has no native FreeBSD port - this may take some time.
On systems with a single logical CPU core, make may fail to build the server when using the --parallel option when calling CMake. If you see error messages related to make, simply omit the --parallel from the command: cmake --build bin --config Release -t BeamMP-Server.
Runtime Dependencies
These are needed to run the server.
Debian, Ubuntu and friends: liblua5.3-0
Other Linux distros: liblua of some kind.
Windows: No libraries.
Support
The BeamMP project is supported by community donations via our Patreon. This brings perks such as Patreon-only channels on our Discord, early access to new updates, and more server keys.