[0.16.51] Crash when autosaving

Place for things which are bugs but we have no idea how to solve them. Things related to hardware, libraries, strange setups, etc.
Post Reply
Telanor
Manual Inserter
Manual Inserter
Posts: 2
Joined: Wed Jun 29, 2016 12:41 am
Contact:

[0.16.51] Crash when autosaving

Post by Telanor »

Walked back into roboport supply range, was waiting for robots to finish resupplying me, autosave popped up, got about half way then crashed. I attached the last 2 modified auto saves. I assume the tmp is the one that was in the process of saving and is now corrupt.
Attachments
_autosave2.zip
(14.55 MiB) Downloaded 87 times
_autosave3.tmp.zip
(8.69 MiB) Downloaded 87 times
factorio-dump-current.dmp
(625.83 KiB) Downloaded 85 times
factorio-current.log
(16.68 KiB) Downloaded 95 times

User avatar
TruePikachu
Filter Inserter
Filter Inserter
Posts: 978
Joined: Sat Apr 09, 2016 8:39 pm
Contact:

Re: [0.16.51] Crash when autosaving

Post by TruePikachu »

Code: Select all

3603.678 Error CrashHandler.cpp:373: Exception Code: c0000005, Address: 0x000000013fb76da8
ModuleBase: 0x000000013fa20000, ImageSize: 013ee000, RelativeAddress: 00156da8
3603.678 Error CrashHandler.cpp:379: Access Violation: Read at address 000002006209C860
3603.678 Error CrashHandler.cpp:393: Exception Context:
rax=000002006209c860, rbx=0000000062a4f850, rcx=0000000077f02f90,
rdx=0000000062a4f7b0, rsi=0000000062a4f7b0, rdi=0000000077f02f90,
rip=000000013fb76da8, rsp=0000000062a4f110, rbp=0000000062a4f7b0,
 r8=0000000077f02fc0,  r9=000000013fa20000, r10=0000000062a4f1c0,
r11=00000000e4486c32, r12=000000000000000c, r13=0000000000000080,
r14=0000000077f02fa8, r15=000000006209c868
3603.678 Crashed in O:\Games\Factorio\bin\x64\factorio.exe (0x000000013fa20000 - 0x0000000140e0e000)
Factorio crashed. Generating symbolized stacktrace, please wait ...
c:\cygwin64\tmp\factorio-build-gumsut\libraries\stackwalker\stackwalker.cpp (924): StackWalker::ShowCallstack
c:\cygwin64\tmp\factorio-build-gumsut\src\util\logger.cpp (408): Logger::writeStacktrace
c:\cygwin64\tmp\factorio-build-gumsut\src\util\logger.cpp (521): Logger::logStacktrace
c:\cygwin64\tmp\factorio-build-gumsut\src\util\crashhandler.cpp (169): CrashHandler::writeStackTrace
c:\cygwin64\tmp\factorio-build-gumsut\src\util\crashhandler.cpp (420): CrashHandler::SehHandler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000772FBC20)
00000000772FBC20 (kernel32): (filename not available): UnhandledExceptionFilter
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000773F9035)
00000000773F9035 (ntdll): (filename not available): longjmp
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000773D7398)
00000000773D7398 (ntdll): (filename not available): _C_specific_handler
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000773EBF9D)
00000000773EBF9D (ntdll): (filename not available): _chkstk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000773C04CA)
00000000773C04CA (ntdll): (filename not available): RtlInitializeResource
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000773EB63E)
00000000773EB63E (ntdll): (filename not available): KiUserExceptionDispatcher
c:\cygwin64\tmp\factorio-build-gumsut\src\entity\entity.cpp (192): Entity::checkPositionConsistency
c:\cygwin64\tmp\factorio-build-gumsut\src\surface\chunk.cpp (100): Chunk::save
c:\cygwin64\tmp\factorio-build-gumsut\src\surface\surface.cpp (621): Surface::save
c:\cygwin64\tmp\factorio-build-gumsut\src\map\map.cpp (1270): Map::save
c:\cygwin64\tmp\factorio-build-gumsut\src\scenario\scenario.cpp (684): Scenario::saveMap
c:\cygwin64\tmp\factorio-build-gumsut\src\scenario\scenario.cpp (612): Scenario::saveAs
c:\cygwin64\tmp\factorio-build-gumsut\src\scenario\parallelscenariosaver.cpp (95): ParallelScenarioSaver::doSave
c:\program files (x86)\microsoft visual studio\2017\buildtools\vc\tools\msvc\14.12.25827\include\thr\xthread (232): std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*)(ParallelScenarioSaver * __ptr64),ParallelScenarioSaver * __ptr64>,std::default_delete<std::tuple<void (__cdecl*)(ParallelScenarioSaver * __ptr64),ParallelScenarioSaver * __ptr64> > > >::_Go
c:\program files (x86)\microsoft visual studio\2017\buildtools\vc\tools\msvc\14.12.25827\include\thr\xthread (211): std::_Pad::_Call_func
d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp (115): thread_start<unsigned int (__cdecl*)(void * __ptr64)>
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000772759CD)
00000000772759CD (kernel32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00000000773D383D)
00000000773D383D (ntdll): (filename not available): RtlUserThreadStart
Looks like a memory fault (look at RAX compared to the other registers, and RAX was dereferenced).

Telanor
Manual Inserter
Manual Inserter
Posts: 2
Joined: Wed Jun 29, 2016 12:41 am
Contact:

Re: [0.16.51] Crash when autosaving

Post by Telanor »

I'm curious how looking at RAX tells you that. Its certainly possible; every once in a blue moon I get a random BSOD that I suspect is from a bad ram module, but I've never been able to catch it with memtest.

User avatar
TruePikachu
Filter Inserter
Filter Inserter
Posts: 978
Joined: Sat Apr 09, 2016 8:39 pm
Contact:

Re: [0.16.51] Crash when autosaving

Post by TruePikachu »

Do you see that `2` in the 6th digit, which isn't present in any of the other registers? And, ignoring that `2`, they all have pretty similar pointers? Bit 42 of what is now in RAX was erronously set while it was in memory; when that pointer was copied to RAX, that bit went along with it, and then the actual crash was when RAX was being dereferenced; without that bit, it points at something in Factorio's memory space, but with it set, it's pointing to the middle of nowhere and, as Factorio neither controls that memory nor has permission to access other processes' memory, causes a memory segmentation fault.

You might have to run your RAM tests for multiple passes with only a single stick of RAM in the machine at a time. I had some faulty RAM a couple years ago, and doing single-stick-at-a-time multiple-pass testing was the only way I was able to actually get a confirmation on the issue from MemTest86+. Regardless, the only way you can reliably pinpoint the faulty stick is if you have one stick at a time, since the BIOS is allowed to do whatever it likes with the memory layout.

kitcat
Long Handed Inserter
Long Handed Inserter
Posts: 66
Joined: Wed Apr 26, 2017 3:11 pm
Contact:

Re: [0.16.51] Crash when autosaving

Post by kitcat »

You could also run Prime95’s torture test, which generally pushes the system more than Memtest but doesn’t tell you which area the problem is in exactly.

Post Reply

Return to “1 / 0 magic”