[0.17.75] Crash LuaHelper::pushChunkPosition

[eradicator]

I've had a weird crash for a few times (3~5ish?) That i can't reproduce properly. As far as i can tell it happens when my custom on_chunk_generated handler runs right after creating a new map. But it only crashes like 1 in 50 times? All the handler does is find_non_colliding_position_in_box() and then try to spawn two simple entities. And while the box is larger than the chunk i can't trigger it by just spawning something outside the generated world either...

I didn't see a dump and the log was full of custom error messages from debugging a control script, so maybe someone could look at the stacktrace and give me a hint what i could try to properly reproduce.

Code: Select all

Factorio crashed. Generating symbolized stacktrace, please wait ...
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\stackwalker\stackwalker.cpp (924): StackWalker::ShowCallstack
c:\cygwin64\tmp\factorio-build-ycfbos\src\util\logger.cpp (537): Logger::writeStacktrace
c:\cygwin64\tmp\factorio-build-ycfbos\src\util\logger.cpp (544): Logger::logStacktrace
c:\cygwin64\tmp\factorio-build-ycfbos\src\util\crashhandler.cpp (184): CrashHandler::writeStackTrace
c:\cygwin64\tmp\factorio-build-ycfbos\src\util\crashhandler.cpp (612): CrashHandler::SignalHandler
minkernel\crts\ucrt\src\appcrt\misc\exception_filter.cpp (219): _seh_filter_exe
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl (304): `__scrt_common_main_seh'::`1'::filt$0
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000007F7F39CE1D4)
000007F7F39CE1D4 (factorio): (filename not available): __C_specific_handler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000007FC686F9B2D)
000007FC686F9B2D (ntdll): (filename not available): RtlLookupFunctionEntry
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000007FC686FAE04)
000007FC686FAE04 (ntdll): (filename not available): DbgPrint
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000007FC686C4B7A)
000007FC686C4B7A (ntdll): (filename not available): KiUserExceptionDispatcher
c:\cygwin64\tmp\factorio-build-ycfbos\src\util\luahelper.cpp (433): LuaHelper::pushChunkPosition
c:\cygwin64\tmp\factorio-build-ycfbos\src\script\luachunkiterator.cpp (109): LuaChunkIterator::luaCall
c:\cygwin64\tmp\factorio-build-ycfbos\src\script\luabinder.hpp (326): LuaBinder<LuaRecipeCategoryPrototype>::callWrapper
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\ldo.c (350): luaD_precall
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\ldo.c (423): luaD_call
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\lvm.c (792): luaV_execute
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\lapi.c (1027): f_call
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\ldo.c (137): luaD_rawrunprotected
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\ldo.c (623): luaD_pcall
c:\cygwin64\tmp\factorio-build-ycfbos\libraries\lua\lapi.c (1053): lua_pcallk
c:\cygwin64\tmp\factorio-build-ycfbos\src\util\luahelper.cpp (3591): LuaHelper::pCallWithStackTrace
c:\cygwin64\tmp\factorio-build-ycfbos\src\script\luacontext.cpp (283): LuaContext::checkRunOnInit
c:\cygwin64\tmp\factorio-build-ycfbos\src\scenario\scenario.cpp (1401): Scenario::setupLuaContext
c:\cygwin64\tmp\factorio-build-ycfbos\src\scenario\scenario.cpp (345): Scenario::loadFactory
c:\cygwin64\tmp\factorio-build-ycfbos\src\appmanager.cpp (613): AppManager::createGame
c:\cygwin64\tmp\factorio-build-ycfbos\src\appmanager.cpp (428): AppManager::restartGame
c:\cygwin64\tmp\factorio-build-ycfbos\src\appmanagerstates.cpp (2411): ConfirmationBoxHelper::executeAndClose
c:\cygwin64\tmp\factorio-build-ycfbos\src\appmanagerstates.hpp (947): InConfirmationBoxTemplate<ConfirmationBoxStrong>::process
c:\cygwin64\tmp\factorio-build-ycfbos\src\appmanager.cpp (227): AppManager::process
c:\cygwin64\tmp\factorio-build-ycfbos\src\mainloop.cpp (507): MainLoop::prePrepare
c:\cygwin64\tmp\factorio-build-ycfbos\src\mainloop.cpp (608): MainLoop::mainLoopStep
c:\cygwin64\tmp\factorio-build-ycfbos\src\mainloop.cpp (377): MainLoop::run
c:\cygwin64\tmp\factorio-build-ycfbos\src\main.cpp (1366): wmain
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl (288): __scrt_common_main_seh
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000007FC677D1842)
000007FC677D1842 (KERNEL32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000007FC686FDF11)
000007FC686FDF11 (ntdll): (filename not available): RtlUserThreadStart
Stack trace logging done
2656.973 Error CrashHandler.cpp:189: Map tick at moment of crash: 0
2656.974 Error Util.cpp:97: Unexpected error occurred. If you're running the latest version of the game you can help us solve the problem by posting the contents of the log file on the Factorio forums.
Please also include the save file(s), any mods you may be using, and any steps you know of to reproduce the crash.
2751.425 Received SIGINT, shutting down
2757.145 Received second SIGINT, terminating immediately

[TruePikachu]

Yuck, Lua stack machine.

My best guess is that the chunk might not actually exist when this event is called. Can you test if you get the crashes still when installing an empty handler? If not, can you post the Lua?

[eradicator]

My best guess is that the chunk might not actually exist when this event is called. Can you test if you get the crashes still when installing an empty handler? If not, can you post the Lua?

That was also my first guess. I tried to additionally spawn something at position {50000,50000} in the handler - a position that most definetly should not exist at that point - and it didn't crash. As the crash happens only very rarely it's difficult to "test" if any change to the code "does not crash" because 98% of the time it doesn't crash in the first place.

Also while i *think* it happens in this handler (it's the last log entry, and i don't do much else with chunks) i can't say if the handler is actually called by on_chunk_generated as i also iterate through all chunks in on_init. And given that the crash only seems to happen when i create a new map this seems more likely.

I've added some notes to the code:

Code: Select all

local function spawn_natural_waypoint(surface,position)
  return surface.create_entity{
    name             = 'er:waypoint-small' ,
    position         = position            ,
    force            = 'neutral'           ,
    create_build_effect_smoke = false      ,
    }
  end
  
local function spawn_rock_formation(surface,position)
  return surface.create_entity{
    name             = 'er:waypoint-rock-formation-1',
    position         = position                      ,
    force            = 'neutral'                     ,
    create_build_effect_smoke = false                ,
    }
  end
  
local one_per_how_many_chunks = (975/15) --15 per km²
This.events{'on_chunk_generated',function(e)
    local mdata = global.some_data --(note: gets savedata from global)
    mdata.free_chunks = mdata.free_chunks + 1
    if mdata.free_chunks < one_per_how_many_chunks then return end
  
    --this will sometimes move the wp to a neighbouring chunk
    local area = Box .shift(
      e.area,{math.random(-16,16), math.random(-16,16)}) --this shifts the e.area by a random offset
  
    local position = e.surface.find_non_colliding_position_in_box(
      'er:waypoint-small', --name
      area               , --search_space
      1                  , --precision
      true               ) --force_to_tile_center

    if position then
      mdata.free_chunks = mdata.free_chunks - one_per_how_many_chunks
      local waystone = spawn_natural_waypoint(e.surface,position)
      spawn_rock_formation(e.surface,position)
      reset_waypoint(waystone) --(note: does some changes to global data)
      Log.debug('[ER Waypoints] natural waypoint created.')
    else
      Log.debug('[ER Waypoints] no position found for natural waypoint ',
        '(free chunks:',mdata.free_chunks,').')
      end
    end}

[eradicator]

Trying to set the position exactly onto the chunk border (the entity is 3x3) also works fine and does not induce the crash.

Code: Select all

position = e.area.right_bottom

[TruePikachu]

Maybe upload the dump file if it happens again, unless Rseding finds it in the automated collection before then? Going by the backtrace in the OP, I'd guess it's at least partially handler-related (going by the C++ calls invoked by Lua).

EDIT: Actually, this might be an error with `create_entity`, looking at the contexts again. Maybe try these situations (without mod code):

• Spawning an entity inside a chunk that doesn't exist, but still within the "bounding box" defined by all existing chunks (e.g. chunks are generated in a dount shape, and spawning an entity inside the "hole" where there isn't a chunk)
• Spawning an entity on the edge of a generated chunk, where it would cross into an ungenerated chunk
• Spawning an entity near the edge of a generated chunk, where it would border an ungenerated chunk

EDIT AGAIN: Looking at the backtrace, once again I'm unsure, but mainly because it depends on how Factorio dispatches the events to Lua, including which context object is used. A dump would clear things up, though, since a Lua backtrace could be extracted from it.

[eradicator]

• Spawning an entity inside a chunk that doesn't exist, but still within the "bounding box" defined by all existing chunks (e.g. chunks are generated in a dount shape, and spawning an entity inside the "hole" where there isn't a chunk)
• Spawning an entity on the edge of a generated chunk, where it would cross into an ungenerated chunk
• Spawning an entity near the edge of a generated chunk, where it would border an ungenerated chunk

I tried a few versions of massively spamming refineries (5x5) all over the place in on_init and surface.get_chunks(), but the only result i got was crashing my system once from running out of memory after waiting 10 minutes for the game to unfreeze *sigh*.

[Rseding91]

Thanks for the report. Without a way to reproduce the crash there's nothing I can do. I looked at the place that's pushing the ChunkPosition into Lua and I don't see anything wrong with how it works.

You could try running memtest86+ to see if maybe you have bad RAM?

[eradicator]

You could try running memtest86+ to see if maybe you have bad RAM?

It seems unlikely that faulty ram would cause several crashes in exactly the same handler.

[Rseding91]

You could try running memtest86+ to see if maybe you have bad RAM?

It seems unlikely that faulty ram would cause several crashes in exactly the same handler.

Unlikely yes but still worth checking since i've never seen that crash before in automatic crash reports.