gennyo
Posts: 68
Joined: 4/3/2019 Status: offline
|
First of all, this post is not a bug report, more akin a Quality of Life feature request. If anyone thinks this is a waste of time, please forget it. Background: You all know how nutty my scenario is. On my Yoga 260s it always hits the 3GB memory ceiling after some hours of running and dump core and quit. It may related with some scheduling mechanism because I found that a much faster CPU could migrate this memory restriction some what. Maybe my CPU just not fast enough for this task and many issued mission stacks one over another, eats away memory. This is not a problem, I know it can’t be helped until I could afford a much faster processor. I always put the game crawling while asleep or working, and the program just dumps core and leaves some Autosaves Data for me to resume the progress after returning to it. This is why any problem related with Autosave is my concern. Build 1147.1 behaves most of the time like I described above. Sometimes it can’t save an autosave because an OutOfMemory exception but it will quit shortly after that, because of memory exhaustion. The exception is like this: 2020-07-16 22:55:17 -- B1147.7 -- Exception of type 'System.OutOfMemoryException' was thrown. Exception: Exception of type 'System.OutOfMemoryException' was thrown. Stack Trace: at System.IO.MemoryStream.set_Capacity(Int32 value) at System.IO.MemoryStream.EnsureCapacity(Int32 value) at System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count) at LZ4.LZ4Stream.FlushCurrentChunk() at LZ4.LZ4Stream.Write(Byte[] buffer, Int32 offset, Int32 count) at System.IO.Stream.InternalCopyTo(Stream destination, Int32 bufferSize) at System.IO.Stream.CopyTo(Stream destination) at ..(Stream ) at Command_Core.ScenContainer.(Stream ) at Command_Core.ScenContainer.(Stream ) Call Stack & Error details: Error at 200055, Exception of type 'System.OutOfMemoryException' was thrown. After build 1147.5, memory management mechanism is much improved as I observed. The program runs much longer between memory related core dumps. Symptom: As the program runs its simulation longer between unintended terminations, a small issue arises. Once the program failed to save an autosave document, it renames Autosave.scen to Autosave_20sec.scen, Autosave_20sec.scen to Autosave_40sec.scen, so on, but not generating a new Autosave.scen because the OutOfMemory exception interrupted the save procedure. In build 1147.1, this behavior seldom removes all the Autosave files because the program can’t run the simulation after two or three consecutive failed save attempts, it just run out of memory. But builds after 1147.5, thanks of the improved simulation core, the program can recover some memory for simulation running, just can’t get enough memory to complete the 60M+ save file generation. After 5 or 6 consecutive failed save attempts, all autosave files will be deleted. Once the program quits because of memory exhaustion, there will be no autosaves left. Workaround: Now I simply copy the most recent autosave file to a safe place before going to sleep or work on my daily jobs. It helps. Possible Solution Suggestion: But I think maybe a fail-safe type of handling would be better? Maybe a check of successful generation of autosave document before renaming the existing files? quote:
Pseudo code: Try{ //autosave procedure to a temp file }catch(e) { //Failed because of any reason: tell the user the autosave file can’t be generated. } //rename the tempfile to Autosave.scen //do the rest renaming. Or maybe keep the existing autosave file after consecutive failures? quote:
Pseudo code: If (public counter_of_failure <3){ Try{ //autosave procedure as before }catch(e) { //gracefully exit the error situation Counter_of_failure=+1 } } Else{ //Failed: tell the user the autosave file can’t be generated. //tell the user the old autosave files will left untouched. }
< Message edited by apache85 -- 7/20/2020 1:30:36 AM >
|