Lua Stack Corruption leads to x86 stack overflow

[lionkor]

Fill out general information
OS (windows, linux, ...): Linux, Debian 12
BeamMP-Server Version: v3.8.5, v3.9.0

Describe the bug
This bug occurred in CaRP.

I debugged the core dump, and essentially the bug is that the stack is in an unexpected state (either due to a threading-related data race, or because it's empty), and then some call across the C++-Lua boundary somewhere panics. This causes the LuaAPI::PanicHandler to be called, which in turn tries to access the stack. This panics Lua, calling the PanicHandler, and so on.

This eventually exhausts the (real) stack of the machine and crashes the server.

The same crash is reproducible with the reproduction steps below, but the CaRP codebase does NOT contain that code. The error is likely different, even though this reproduction might help fix the symptom.

I would carefully suggest running the server with some sanitizers like TSAN or valgrind in production.

To Reproduce
Steps to reproduce similar behavior:

1. Make a Lua plugin with the content error(nil)
2. Run the server

Expected behavior
A panic log and the server continues to run as usual, just without the errored plugin.

[lionkor]

toino. has core dumps etc. if relevant

[lionkor]

Does that change just remove tracebacks entirely?

[WiserTixx]

It reverts #350 as that change was observed to trigger this bug. However I did not mean to close this issue with that PR, because it does not resolve it. It's just a temporary mitigation for the constant crashes.

[boubouleuh]

#474 i edited the PanicHandler function in that PR because while debugging i found that it was recursively panicking because of sol::stack::get So it successfully solve this issue by just printing something like [LUA ERROR] Failed: "Resources\Server\Test\main.lua": like intended
https://github.com/BeamMP/BeamMP-Server/pull/474/changes#diff-6da0497b6b1580ec659dd1e45427e7fba4b4e6e8fc078a69bd296aed2b28876aR438-R444