[0.12.19] [Oxyd] [AI RELATED] Crash at set time in save

[Reika]

Every time my save reaches a certain point (now about 10s after the last save, but this issue has been in existence for over a week, since back when the issue was hours of gameplay out), it simply crashes to desktop. The logged error is as follows:

Code: Select all

  27.213 Loading map C:/Users\Reika\AppData\Roaming\Factorio\saves\Light_Modded-compression-natevo-furn.zip
  27.265 Info Scenario.cpp:123: Map version 0.12.19-0
Factorio crashed. Generating symbolized stacktrace, please wait ...
c:\cygwin64\tmp\factorio-iw2tsk\libraries\stackwalker\stackwalker.cpp (923): StackWalker::ShowCallstack
c:\cygwin64\tmp\factorio-iw2tsk\src\util\logger.cpp (284): Logger::writeStacktrace
c:\cygwin64\tmp\factorio-iw2tsk\src\util\logger.cpp (338): Logger::logStacktrace
c:\cygwin64\tmp\factorio-iw2tsk\src\util\crashhandler.cpp (81): CrashHandler::writeStackTrace
c:\cygwin64\tmp\factorio-iw2tsk\src\util\crashhandler.cpp (90): CrashHandler::SehHandler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076C6B990)
0000000076C6B990 (kernel32): (filename not available): UnhandledExceptionFilter
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076E7A0B8)
0000000076E7A0B8 (ntdll): (filename not available): EtwEventSetInformation
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076E08008)
0000000076E08008 (ntdll): (filename not available): _C_specific_handler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076E1905D)
0000000076E1905D (ntdll): (filename not available): RtlDecodePointer
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076E08C0F)
0000000076E08C0F (ntdll): (filename not available): RtlUnwindEx
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076E3D948)
0000000076E3D948 (ntdll): (filename not available): KiUserExceptionDispatcher
c:\cygwin64\tmp\factorio-iw2tsk\src\ai\commandable.cpp (113): Commandable::runBehavior
c:\cygwin64\tmp\factorio-iw2tsk\src\entity\unit.cpp (217): Unit::update
c:\cygwin64\tmp\factorio-iw2tsk\src\surface\chunk.cpp (441): Chunk::update
c:\cygwin64\tmp\factorio-iw2tsk\src\surface\surface.cpp (818): Surface::update
c:\cygwin64\tmp\factorio-iw2tsk\src\map\map.cpp (914): Map::update
c:\cygwin64\tmp\factorio-iw2tsk\src\game.cpp (144): Game::update
c:\cygwin64\tmp\factorio-iw2tsk\src\scenario\scenario.cpp (729): Scenario::update
c:\cygwin64\tmp\factorio-iw2tsk\src\mainloop.cpp (262): MainLoop::gameUpdateStep
c:\cygwin64\tmp\factorio-iw2tsk\src\mainloop.cpp (368): MainLoop::updateLoop
c:\boost_1_58_0\boost\function\function_template.hpp (160): boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,void (__cdecl*)(ThreadBarrier * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,bool * __ptr64,bool),boost::_bi::list5<boost::_bi::value<ThreadBarrier * __ptr64>,boost::_bi::value<boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64>,boost::_bi::value<boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64>,boost::_bi::value<bool * __ptr64>,boost::_bi::value<bool> > >,void>::invoke
c:\cygwin64\tmp\factorio-iw2tsk\src\util\thread.cpp (34): Thread::loop
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000000013F7CC883)
000000013F7CC883 (Factorio): (filename not available): boost::`anonymous namespace'::thread_start_function
f:\dd\vctools\crt\crtw32\startup\threadex.c (376): _callthreadstartex
f:\dd\vctools\crt\crtw32\startup\threadex.c (354): _threadstartex
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076BE5A4D)
0000000076BE5A4D (kernel32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000076E1B831)
0000000076E1B831 (ntdll): (filename not available): RtlUserThreadStart
  69.119 Error Util.cpp:63: Unexpected error occurred. You can help us to solve the problem by posting the contents of the log file on the Factorio forums.

I am not familiar with this format, but it almost looks like it is crashing on making a crash report, something I thought only Minecraft did.

I do notice mentions of "chunk", "surface", and "map", but no worldgen was running at the time (at least it should not have been).


EDIT:
Running the "kill all units" command on "enemy" (i.e. despawning all biters and spitters) fixed it. So it appears there was a time bomb of sorts in the AI logic (and "AI" does indeed appear in the log).

[bobingabout]

I think this was either fixed in 0.12.19, or was fixed for 0.12.20, but there was a biter related crash fixed recently, this could be related to it. This specific issue I'm thinking, the game would crash when the AI destroyed a building.

[Oxyd]

Duplicate.

Also, do not post partial logs in the future. When we log something, it's because we want to see it. In this instance, you omitted your version information, which you also neglected to provide in the post itself – so I'm going to just assume you're using 0.12.18.

Since this was fixed in 0.12.19, you can just update.

[prg]

Well the log does contain

Code: Select all

  27.265 Info Scenario.cpp:123: Map version 0.12.19-0

so it might be something different after all.

[Oxyd]

Well the log does contain

Code: Select all

  27.265 Info Scenario.cpp:123: Map version 0.12.19-0

so it might be something different after all.

So it does. I'm officially blind, then. Sorry.

In that case, I'm going to need the save and the mod folder if not vanilla.

[Reika]

There was a biter related crash fixed recently, this could be related to it. This specific issue I'm thinking, the game would crash when the AI destroyed a building.

You are very likely on to something, as the crash happened seconds after biters took out a MK4 logistics robot (that decided to idle near a "rendezvous point" for the biters). Killing the biters in that group stopped them from attacking the bot and thus avoided the crash.

I think this was either fixed in 0.12.19, or was fixed for 0.12.20

Duplicate.

Also, do not post partial logs in the future. When we log something, it's because we want to see it. In this instance, you omitted your version information, which you also neglected to provide in the post itself – so I'm going to just assume you're using 0.12.18.

Since this was fixed in 0.12.19, you can just update.

I am using the newest version of Factorio that I can update to (i.e. "check for updates" returns nothing).

Also, I truncated the log because the first half is nothing but loading and hardware info, which I doubt to be useful and triples the length. And in the community I come from, posting entire logs - as opposed to just the stacktraces - is actually frowned upon, and where in most cases, in entire-log reports, the "bug" turns out to be user error of the "I installed two obviously incompatible things together" or "I TL;DR'ed the entire documentation and now have no idea how to do anything, so I'm making a bug report" variety, usually barely coherent at that.

Well the log does contain

Code: Select all

  27.265 Info Scenario.cpp:123: Map version 0.12.19-0

so it might be something different after all.

So it does. I'm officially blind, then. Sorry.

There is very much a time and place to berate the user. Trust me, I have a great deal of experience - and a bit of a reputation - in that field. However, now was not one of them, and it is imperative to single-, double-, and triple-check that such a response is warranted before doing so, or be sure that the initial post is so obviously unforgivable you start assuming you need to count the user's IQ points in the single digits.

In that case, I'm going to need the save and the mod folder if not vanilla.

The good news:
Here they are:
http://www.mediafire.com/download/1d7cd ... o-furn.zip
http://www.mediafire.com/download/78l0h ... 282%29.rar

The bad news:
Because of your initial reply, I gave up trying to seek help, and continued playing the save. That means that though it may well occur again in the save - speeding up game time by 200x is how I first noticed it - the easily-repeatable case is gone. You might be able to manually reproduce it by spawning more logistics robots next to biter camps.


If it is a mod, I would start with Natural Evolution, as it substantially changes biter behavior. That said, it is all through a control.lua and thus should be incapable of triggering an internal C++ crash like that.

[daniel34]

If it is a mod, I would start with Natural Evolution, as it substantially changes biter behavior. That said, it is all through a control.lua and thus should be incapable of triggering an internal C++ crash like that.

Guess what? [Oxyd] Error Util.cpp:63: Unexpected error occurred

This was caused by Natural Evolution ordering a group of biters to attack a disconnected player. I've fixed it by disallowing access to LuaPlayer::character if the player is currently disconnected, so Natural Evolution (and possibly other mods) will have to be updated to stop trying to do that.

So: Fixed for 0.12.18.

Did you use your save with <= 0.12.17 and had Natural Evolution on? I'm not sure how that fix works but maybe there are effects from previous versions...

EDIT: Natural Evolution hasn't been updated since then, so there is no fix for that right now: Error displayed by Natural Evolution when running on 0.12.19
Quote from that:

I'm also playing with bob's mods and had to delete natural enemies, as it was causing crash, when you reach 57% of evolution.

[Reika]

If it is a mod, I would start with Natural Evolution, as it substantially changes biter behavior. That said, it is all through a control.lua and thus should be incapable of triggering an internal C++ crash like that.

Guess what? [Oxyd] Error Util.cpp:63: Unexpected error occurred

This was caused by Natural Evolution ordering a group of biters to attack a disconnected player. I've fixed it by disallowing access to LuaPlayer::character if the player is currently disconnected, so Natural Evolution (and possibly other mods) will have to be updated to stop trying to do that.

So: Fixed for 0.12.18.

Did you use your save with <= 0.12.17 and had Natural Evolution on? I'm not sure how that fix works but maybe there are effects from previous versions...

I doubt this to be related. I did not log in or out any time near the crash, and nothing happened in the save to "send" the biters to me (i.e. no logic would have run to run an attack command), and the "rocket silo attack" in NatEvo (the only active "target the player" code I know of in it) is disabled due to the extreme lag that a thousand moving biters cause. Additionally, I was standing in the middle of my base (next to the "Fluid Processing" station for those with the save), and no biter would have had the ability to see me and choose to attack that way, either.


Answering your initial question, the save started about three weeks ago, so yes, it has gone through several versions. That said, NatEvo was only added more recently; I do not remember if it was present when I was using 12.17. I suspect not, but that is only a hazy guess.

EDIT: To respond to the edit, there may be something to that; the crash does seem to become more likely as evolution factor rises. That said, that may simply be due to the biters getting stronger and thus penetrating further or being finally able to destroy something.

[Oxyd]

Also, I truncated the log because the first half is nothing but loading and hardware info, which I doubt to be useful and triples the length. And in the community I come from, posting entire logs - as opposed to just the stacktraces - is actually frowned upon, and where in most cases, in entire-log reports, the "bug" turns out to be user error of the "I installed two obviously incompatible things together" or "I TL;DR'ed the entire documentation and now have no idea how to do anything, so I'm making a bug report" variety, usually barely coherent at that.

Tripling the length is not an issue. Some users post an excerpt from the log like you did and then post a link to the full log stored somewhere, that's also fine if you'd prefer to do it that way. Nevertheless, the information in there is often useful and I'd like to see it.

Well the log does contain

Code: Select all

  27.265 Info Scenario.cpp:123: Map version 0.12.19-0

so it might be something different after all.

So it does. I'm officially blind, then. Sorry.

There is very much a time and place to berate the user. Trust me, I have a great deal of experience - and a bit of a reputation - in that field. However, now was not one of them, and it is imperative to single-, double-, and triple-check that such a response is warranted before doing so, or be sure that the initial post is so obviously unforgivable you start assuming you need to count the user's IQ points in the single digits.

I had absolutely no intention to berate you here. I missed the version information in your post, thought you didn't provide it and prg corrected me. That's what happened here, at least so far as I can see. Whilst I also enjoy some good old Internet berating, this was not one of the times.

In that case, I'm going to need the save and the mod folder if not vanilla.

The good news:
Here they are:
http://www.mediafire.com/download/1d7cd ... o-furn.zip
http://www.mediafire.com/download/78l0h ... 282%29.rar

The bad news:
Because of your initial reply, I gave up trying to seek help, and continued playing the save. That means that though it may well occur again in the save - speeding up game time by 200x is how I first noticed it - the easily-repeatable case is gone. You might be able to manually reproduce it by spawning more logistics robots next to biter camps.

That really is a shame. So far I haven't been able to reproduce the crash, whether by spawning logistic robots next to biters or by just waiting. If you experience the crash again, a save close to the point of crashing would be really helpful.

If it is a mod, I would start with Natural Evolution, as it substantially changes biter behavior. That said, it is all through a control.lua and thus should be incapable of triggering an internal C++ crash like that.

There have been Lua-induced crashes in Factorio in the past. The C++-Lua interface is a chunk of code like anything else, and as such it has bugs.

[Reika]

Also, I truncated the log because the first half is nothing but loading and hardware info, which I doubt to be useful and triples the length. And in the community I come from, posting entire logs - as opposed to just the stacktraces - is actually frowned upon, and where in most cases, in entire-log reports, the "bug" turns out to be user error of the "I installed two obviously incompatible things together" or "I TL;DR'ed the entire documentation and now have no idea how to do anything, so I'm making a bug report" variety, usually barely coherent at that.

Tripling the length is not an issue. Some users post an excerpt from the log like you did and then post a link to the full log stored somewhere, that's also fine if you'd prefer to do it that way. Nevertheless, the information in there is often useful and I'd like to see it.

Well the log does contain

Code: Select all

  27.265 Info Scenario.cpp:123: Map version 0.12.19-0

so it might be something different after all.

So it does. I'm officially blind, then. Sorry.

There is very much a time and place to berate the user. Trust me, I have a great deal of experience - and a bit of a reputation - in that field. However, now was not one of them, and it is imperative to single-, double-, and triple-check that such a response is warranted before doing so, or be sure that the initial post is so obviously unforgivable you start assuming you need to count the user's IQ points in the single digits.

I had absolutely no intention to berate you here. I missed the version information in your post, thought you didn't provide it and prg corrected me. That's what happened here, at least so far as I can see. Whilst I also enjoy some good old Internet berating, this was not one of the times.

It was phrases like "if we put information in the log, it means we want to see it" that led me to that conclusion.

In that case, I'm going to need the save and the mod folder if not vanilla.

The good news:
Here they are:
http://www.mediafire.com/download/1d7cd ... o-furn.zip
http://www.mediafire.com/download/78l0h ... 282%29.rar

The bad news:
Because of your initial reply, I gave up trying to seek help, and continued playing the save. That means that though it may well occur again in the save - speeding up game time by 200x is how I first noticed it - the easily-repeatable case is gone. You might be able to manually reproduce it by spawning more logistics robots next to biter camps.

That really is a shame. So far I haven't been able to reproduce the crash, whether by spawning logistic robots next to biters or by just waiting. If you experience the crash again, a save close to the point of crashing would be really helpful.

If it is a mod, I would start with Natural Evolution, as it substantially changes biter behavior. That said, it is all through a control.lua and thus should be incapable of triggering an internal C++ crash like that.

There have been Lua-induced crashes in Factorio in the past. The C++-Lua interface is a chunk of code like anything else, and as such it has bugs.

Good news: I have one, but you will need to update the modpack as well.

The crash happens about 15s after the save loads, immediately after biters damage something (very likely a logistics bot, plasma turret, or wall), very likely near one of the "radar outposts".

http://www.mediafire.com/download/sladn ... o-furn.zip
http://www.mediafire.com/download/ofs86 ... 283%29.rar

[kovarex]

Just one unrelated question, why do you keep the mods unpacked in the mods folder? They are supposed to be zip packages, so instead of thousands of files, you have a few.

[kovarex]

As it crashes for me in 0.12.19, but in our 0.12.20 it doesn't It is most probably fixed by some of the changes we did, so it is fixed for the next release.