Segmentation fault under specific conditions (apparently unloading the entity the player is attached to)

[andriyndev]

Minetest version

Minetest 5.9.0-dev-debug-c4703a7f1 (Linux)
Using LuaJIT 2.1.1713773202
Built by GCC 11.4
Running on Linux/6.5.0-35-generic x86_64
BUILD_TYPE=Debug
RUN_IN_PLACE=1
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1
STATIC_SHAREDIR="."
STATIC_LOCALEDIR="locale"

Irrlicht device

No response

Operating system and version

Linux Mint 21.3 Cinnamon

CPU model

Intel© Core™ i3-7100U CPU @ 2.40GHz × 2

GPU model

Intel Corporation HD Graphics 620

Active renderer

No response

Summary

The server can crash with Segmentation Fault error when riding an Advtrains train for some time. The bug can be easily reproduced when using a modified version of Advtrains from https://gitlab.com/tunnelers-abyss/advtrains which allows larger speed of trains (I had also once managed to reproduce it with the standard version of Advtrains but it was much more difficult). It's not because of bugs in the mod, because even if it is, potential bugs in mods shouldn't cause Segmentation Fault in the whole engine. Coredump pointed that the source of the crash is l_object.cpp:728:

Core was generated by `./bin/minetest'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00006087f0369155 in ObjectRef::l_set_attach (L=0x79a46e65b380)
    at /home/andrii/git/minetest/src/script/lua_api/l_object.cpp:728
728			old_parent->removeAttachmentChild(sao->getId());
[Current thread is 1 (Thread 0x79a46cad6640 (LWP 5562))]
(gdb) p sao
$1 = (ServerActiveObject *) 0x79a4401a6960
(gdb) p old_parent
$2 = (ServerActiveObject *) 0x0

Also, before the crash, there was the following line in the log:
WARNING[Server]: PlayerSAO::step() id=1 is attached to nonexistent parent. This is a bug.

Steps to reproduce

1. Install Advtrains mod from https://gitlab.com/tunnelers-abyss/advtrains
2. Build a long straight railroad (1000m was enough for me), in each end of which the train automatically changes direction (using "Station/Stop Rail") so that it could run infinitely
3. Run the train with the max speed, and wait until the Seg.fault happens. To speed up the process, you can try to teleport to a distant location when riding a train (under normal conditions you can be automatically teleported back to the train but sometimes it might cause the area with the train to unload that is apparently the reason of the bug. Also decreasing the viewing range to minimum may help.

Restricting max memory for the app via
systemd-run --scope -p MemoryMax=500M --user ./bin/minetest
didn't help to reproduce the bug.

[sfan5]

Please post the entire backtrace.

[andriyndev]

Backtrace:

(gdb) bt
#0  0x00006087f0369155 in ObjectRef::l_set_attach (L=0x79a46e65b380)
    at /home/andrii/git/minetest/src/script/lua_api/l_object.cpp:728
#1  0x00006087f02f3193 in script_exception_wrapper (L=0x79a46e65b380, 
    f=0x6087f0368ee6 <ObjectRef::l_set_attach(lua_State*)>)
    at /home/andrii/git/minetest/src/script/common/c_internal.cpp:41
#2  0x000079a4a95f2aab in ?? () from /usr/local/lib/libluajit-5.1.so.2
#3  0x000079a4a96078c9 in lua_pcall () from /usr/local/lib/libluajit-5.1.so.2
#4  0x00006087f03044a0 in ScriptApiBase::runCallbacksRaw (this=0x79a44c030d40, nargs=1, 
    mode=RUN_CALLBACKS_MODE_FIRST, fxn=0x6087f083844a "environment_Step")
    at /home/andrii/git/minetest/src/script/cpp_api/s_base.cpp:377
#5  0x00006087f030b9a0 in ScriptApiEnv::environment_Step (this=0x79a44c030b78, dtime=0.0585029982)
    at /home/andrii/git/minetest/src/script/cpp_api/s_env.cpp:56
#6  0x00006087f0616f76 in ServerEnvironment::step (this=0x79a44c3b55d0, dtime=0.0585029982)
    at /home/andrii/git/minetest/src/serverenvironment.cpp:1564
#7  0x00006087f05dc5c6 in Server::AsyncRunStep (this=0x6087f2187db0, dtime=0.0585029982, initial_step=false)
    at /home/andrii/git/minetest/src/server.cpp:680
#8  0x00006087f05d75a7 in ServerThread::run (this=0x6087f2959760) at /home/andrii/git/minetest/src/server.cpp:131
#9  0x00006087f03c3cc2 in Thread::threadProc (thr=0x6087f2959760)
    at /home/andrii/git/minetest/src/threading/thread.cpp:194
#10 0x00006087f03c4b2a in std::__invoke_impl<void, void (*)(Thread*), Thread*> (
    __f=@0x79a44c387070: 0x6087f03c3c28 <Thread::threadProc(Thread*)>) at /usr/include/c++/11/bits/invoke.h:61
#11 0x00006087f03c4a9d in std::__invoke<void (*)(Thread*), Thread*> (
    __fn=@0x79a44c387070: 0x6087f03c3c28 <Thread::threadProc(Thread*)>) at /usr/include/c++/11/bits/invoke.h:96
#12 0x00006087f03c49fd in std::thread::_Invoker<std::tuple<void (*)(Thread*), Thread*> >::_M_invoke<0ul, 1ul> (
    this=0x79a44c387068) at /usr/include/c++/11/bits/std_thread.h:259
#13 0x00006087f03c49b2 in std::thread::_Invoker<std::tuple<void (*)(Thread*), Thread*> >::operator() (
    this=0x79a44c387068) at /usr/include/c++/11/bits/std_thread.h:266
#14 0x00006087f03c4992 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(Thread*), Thread*> > >::_M_run (this=0x79a44c387060) at /usr/include/c++/11/bits/std_thread.h:211
#15 0x000079a4a8cdc253 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#16 0x000079a4a8894ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#17 0x000079a4a8926850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)