Page 1 of 1

[0.14.x] [kovarex] Segfault shortly after map load

Posted: Tue Sep 20, 2016 3:25 am
by dauphin
Honestly, I keep reading the stack trace as though the SIGSEGV happened in Logger::logStacktrace, but that can't be right. So it must've been in Entity::setPositionWithoutMapRegistration.

In any case, I had started Factorio, and loaded a different save from a multiplayer game. An experimental version of the Robot Army mod had caused the game to stop. You'll see that at 32.260 in the log. So this returned me to the main menu.

About 20 seconds later, I decided to try to load a previous autosave to see if the same problem would occur at the same game tick. I didn't get that far. Instead, about 5 seconds after I loaded the autosave, the game segfaulted and left behind the stack trace here.

Code: Select all

  66.213 Error CrashHandler.cpp:210: Received SIGSEGV
Factorio crashed. Generating symbolized stacktrace, please wait ...
#0  0x1005de702 in Logger::logStacktrace(StackTraceInfo*) (in factorio) (Logger.cpp:386)
#1  0x1005d6f29 in CrashHandler::writeStackTrace() (in factorio) (CrashHandler.cpp:106)
#2  0x1005d6ebe in CrashHandler::SignalHandler(int) (in factorio) (CrashHandler.cpp:215)
#3  0x7fff9f3dd52a in 0x7fff9f3dd52a
#4  0x0 in 0x0
#5  0x1000a3c84 in Entity::setPositionWithoutMapRegistration(RealPosition const&) (in factorio) (Entity.cpp:454)
#6  0x100114d00 in Vehicle::update() (in factorio) (Vehicle.cpp:132)
#7  0x10011350d in Car::update() (in factorio) (Car.cpp:262)
#8  0x1005a8283 in Chunk::update(unsigned int, Surface&) (in factorio) (list_node.hpp:63)
#9  0x10046bb20 in Surface::update() (in factorio) (Surface.cpp:861)
#10 0x10026132d in Map::update() (in factorio) (Map.cpp:1117)
#11 0x100260ea1 in Game::update() (in factorio) (Game.cpp:144)
#12 0x10044bdef in Scenario::update() (in factorio) (Scenario.cpp:836)
#13 0x100450436 in MainLoop::gameUpdateStep(MultiplayerManagerBase*, Scenario*, AppManager*, MainLoop::HeavyMode) (in factorio) (MainLoop.cpp:720)
#14 0x10044ef23 in MainLoop::gameUpdateLoop(MainLoop::HeavyMode) (in factorio) (MainLoop.cpp:590)
#15 0x1005e6edb in WorkerThread::loop() (in factorio) (WorkerThread.cpp:35)
#16 0x1009597e1 in void* std::__1::__thread_proxy<std::__1::tuple<void (WorkerThread::*)(), WorkerThread*> >(void*) (in factorio) (thread:349)
#17 0x7fff8e21199d in 0x7fff8e21199d
#18 0x7fff8e21191a in 0x7fff8e21191a
#19 0x7fff8e20f351 in 0x7fff8e20f351
You can find the full log, all the mods and the save file in this Dropbox folder: https://www.dropbox.com/sh/yi83a4roeb00 ... TWYzhKVyWa


Fantastic game, by the way. Hopefully this is somehow helpful!

Re: Segfault shortly after map load

Posted: Tue Sep 20, 2016 3:28 am
by dauphin
For what it's worth, I find this segfault to be 100% reproducible. As in, if I restart Factorio and try to load the same save file, it segfaults every time.

Re: Segfault shortly after map load

Posted: Tue Sep 20, 2016 8:26 am
by Rseding91
Do you know how it got into this state?

Re: [0.14.x] [kovarex] Segfault shortly after map load

Posted: Tue Sep 20, 2016 12:54 pm
by kovarex
The bug is, that the player is in a vehicle above water.
Our code tries to get him out of the car before the character is disconnected from the map. But as it can't get him from the car as there is water around, it can't and it messes up.

So I fixed by forcing the player to get out of the car, or die trying.

This means, that disconnecting from a multiplayer game above water means you will die.
We could improve it in future versions, that both the player and the care are removed from the map so they can be both reconnected to the map when they connect again, but it is more of a feature request.

Re: [0.14.x] [kovarex] Segfault shortly after map load

Posted: Tue Sep 20, 2016 1:32 pm
by kovarex
Ok, I changed it a little. The player don't get killed. The game tries to put him back into the vehicle if it still exists. If it doesn't exist, and the player is over water, he is teleported to the spawn position.

Re: [0.14.x] [kovarex] Segfault shortly after map load

Posted: Tue Sep 20, 2016 2:23 pm
by dauphin
Ahh, makes sense. Thanks for fixing this! I know allowing mods makes for a lot of weird situations. But that sounds like a more than reasonable fix to me.