[0.16.51] Crash when autosaving
[0.16.51] Crash when autosaving
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 107 times
-
- _autosave3.tmp.zip
- (8.69 MiB) Downloaded 107 times
-
- factorio-dump-current.dmp
- (625.83 KiB) Downloaded 116 times
-
- factorio-current.log
- (16.68 KiB) Downloaded 113 times
- TruePikachu
- Filter Inserter
- Posts: 978
- Joined: Sat Apr 09, 2016 8:39 pm
- Contact:
Re: [0.16.51] Crash when autosaving
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
Re: [0.16.51] Crash when autosaving
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.
- TruePikachu
- Filter Inserter
- Posts: 978
- Joined: Sat Apr 09, 2016 8:39 pm
- Contact:
Re: [0.16.51] Crash when autosaving
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.
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.
Re: [0.16.51] Crash when autosaving
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.