[0.12.0] Crash on 4th level of campaign

Taron · Post by **Taron** » Wed Jul 22, 2015 6:34 pm

Hi there, I encountered a reproducable crash on the 4th level of the campaign

 0.001 2015-07-22 20:01:56; Factorio 0.12.0 (Build 103, win64)
   0.001 Operating system: Windows 7 Service Pack 1
   0.001 Read data path: C:/Enter/Factorio/data
   0.001 Write data path: C:/Users/****/AppData/Roaming/Factorio
   0.001 Binaries path: C:/Enter/Factorio/bin
   0.422 Initialised Direct3D: NVIDIA GeForce GTX 680; driver: nvd3dumx.dll 9.18.13.5012
   0.459 Graphics options: [FullScreen: true] [VSync: true] [UIScale: 100%] [MultiSampling: X 8] [Graphics quality: normal] [Video memory usage: all]
   0.588 Loading mod core 0.0.0 (data.lua)
   0.590 Loading mod base 0.12.0 (data.lua)
   1.045 Initial atlas bitmap size is 16384
   1.047 Created atlas bitmap 16384x7658
   7.440 Info Updater.cpp:720: Downloading https://www.factorio.com/updater/get-available-versions?username=****&token=<private>&apiVersion=2
   8.119 0 packages available to download (experimental updates enabled).
   8.140 Factorio initialised
  13.801 Loading map C:/Users\****\AppData\Roaming\Factorio\saves\_autosave1.zip
  13.900 Info Scenario.cpp:160: Map version 0.12.0-36
Factorio crashed. Generating symbolized stacktrace, please wait ...
c:\temp\factorio-5829127a\libraries\stackwalker\stackwalker.cpp (923): StackWalker::ShowCallstack
c:\temp\factorio-5829127a\src\util\logger.cpp (283): Logger::writeStacktrace
c:\temp\factorio-5829127a\src\util\logger.cpp (337): Logger::logStacktrace
c:\temp\factorio-5829127a\src\util\crashhandler.cpp (79): CrashHandler::writeStackTrace
c:\temp\factorio-5829127a\src\util\crashhandler.cpp (88): CrashHandler::SehHandler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000774AB9B0)
00000000774AB9B0 (kernel32): (filename not available): UnhandledExceptionFilter
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000776B99C8)
00000000776B99C8 (ntdll): (filename not available): EtwEventSetInformation
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000077647FA8)
0000000077647FA8 (ntdll): (filename not available): _C_specific_handler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000776591AD)
00000000776591AD (ntdll): (filename not available): RtlDecodePointer
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0000000077648BAF)
0000000077648BAF (ntdll): (filename not available): RtlUnwindEx
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000000007767DB38)
000000007767DB38 (ntdll): (filename not available): KiUserExceptionDispatcher
c:\temp\factorio-5829127a\src\ai\commander.cpp (104): Commander::setMultiCommand
c:\temp\factorio-5829127a\src\script\luasurface.cpp (456): LuaSurface::luaSetMultiCommand
c:\temp\factorio-5829127a\src\script\luabinder.hpp (300): LuaBinder<LuaSurface>::callWrapper
c:\temp\factorio-5829127a\libraries\lua\ldo.c (320): luaD_precall
c:\temp\factorio-5829127a\libraries\lua\lvm.c (723): luaV_execute
c:\temp\factorio-5829127a\libraries\lua\lapi.c (920): f_call
c:\temp\factorio-5829127a\libraries\lua\ldo.c (133): luaD_rawrunprotected
c:\temp\factorio-5829127a\libraries\lua\lapi.c (946): lua_pcallk
c:\temp\factorio-5829127a\src\script\luagamescript.cpp (1751): LuaGameScript::signallingPCall
c:\temp\factorio-5829127a\src\script\luagamescript.cpp (523): LuaGameScript::runEventHandler
c:\temp\factorio-5829127a\src\script\luaeventdispatcher.cpp (164): LuaEventDispatcher::run
c:\temp\factorio-5829127a\src\script\luacontext.cpp (111): LuaContext::update
c:\temp\factorio-5829127a\src\scenario\scenario.cpp (731): Scenario::update
c:\temp\factorio-5829127a\src\mainloop.cpp (250): MainLoop::gameUpdateStep
c:\temp\factorio-5829127a\src\mainloop.cpp (351): 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:\temp\factorio-5829127a\src\util\thread.cpp (34): Thread::loop
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000000013F61B163)
000000013F61B163 (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: 00000000774259CD)
00000000774259CD (kernel32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000000007765B981)
000000007765B981 (ntdll): (filename not available): RtlUserThreadStart

By the way, you should avoid publishing your symbols (.pdb) for windows builds with the software. It really simplifies the reverse engineering of the application (e.g. cracking it for instance). Its defintely the wrong way to go just to get a callstack in the log file. Way better would be something like CrashRpt (i think win only) or googleBreakpad and the send the minidumps of a crash automatically (with user agreement) to a server. Everytime you release a build your continous integration system should store the symbols in a symbol server. With that you can easily debug the minidumps of any version with a stacktrace and more

and its easy to setup. Plus users dont have to search for log files and post them here. Also the pdb is roughly 100Mb. Its 33% of the whole application, so additionally you save a lot of traffic.

Just on Topic a quote from an article on PDBs: http://www.wintellect.com/devcenter/jro ... ly-contain

Native binary PDB files are extremely sensitive. Native PDB files contain the following data (if they are not stripped):

Public, private, and static function addresses

Global variable names and addresses

Parameter and local variable names and offsets where to find them on the stack

Type data consisting of class, structure, and data definitions

Frame Pointer Omission (FPO) data, which is the key to native stack walking on x86

Source file names and their lines
If you hand those over to a customer, you’ve given them everything short of source files. In fact, armed with the full native PDB file, it’s not too hard to write a tool with the public DBGHELP symbol API to write a tool that recreates your header files. If you value your job, you never want to let your native PDB files find their way outside your firewall.