Hm, Factorio 0.14.20, Linux, Headless keeps on crashing on my servers.
But (I'm running 3 Servers on the same machine) they all crash in parallel.
As I mentioned before, the Log in the logfile is different to the one output to the console, hence 2 logs per Server.
I dont think it's related to the map, since it just crashed on a brand new map with 0 seconds playtime.
A very similar crash just happened again, so I'm attaching 2 x 2 logs.
My Console's scrollback is only 1000 lines, which is why you don't see the beginning of launching the Server in case of longjump1.txt
I'm running a Fedora Server Version 24 Server, virtualized on VMWare ESXi.
Don't have a lot of other stuff running on the Server, but I haven't seen anything else crash due to memory corruption / violations.
Since I'm the only one with this problem it could just be my install, or I'm haunted by a rare bug, I dont know.
This is similar to This Bug
Thanks for your awesome work, guys and gals. Keep it up
Cheers,
Titan21
[cube] [0.14.20] longjmp causes uninitialized stack frame
[cube] [0.14.20] longjmp causes uninitialized stack frame
- Attachments
-
- birthday.zip
- (690.83 KiB) Downloaded 174 times
-
- longjump2-factorio-current.log
- (4.68 KiB) Downloaded 224 times
-
- longjump2.txt
- (11.2 KiB) Downloaded 220 times
-
- longjump1-factorio-current.log
- (22.74 KiB) Downloaded 222 times
-
- longjump1.txt
- (70.56 KiB) Downloaded 224 times
Re: [cube] [0.14.20] longjmp causes uninitialized stack frame
This looks like it's caused by a bug in old cURL version, and we've updated it in 0.14.21. Open a new report if you still have problems.
Re: [cube] [0.14.20] longjmp causes uninitialized stack frame
Correction -- the newer curl version was added to Factorio before this report, so it didn't fix anything. Turns out the workaround in newer curl has to be enabled explicitly, which we will do in 0.15