Good morning, I have been encountering an error after doing an Apollo-style Minmus landing in the stock solar system in a science save. When attempting to switch back to the command module in orbit through the tracking staion, the game freezes, then crashes without any message (essentially, closes itself). Ascending to orbit in the lander and then switching to map view to create a flight plan crashes the game instantly. A satellite from an earlier mission orbiting Minmus produces the same result.
I have multiple part mods such as BDB, and environment mods like Parallax and EVE. The solar system is the stock one and not unmodified, but all vessels this occurs with contained modded parts from BDB.
All files relevant are in this gist here.
I upgraded from Hardy and played on the new release multiple times before this crash occurred, and it does not seem to occur with Kerbin or the Mun or interplanetary space; I have not tested other planets.
In the stderr file, I can see something about a duplicated time mismatch, and googling about this in context with KSP brought me nothing. I hope this can be helped :)
Thank you for reporting. From the look of your logs it seems that some data structure related to trajectories got corrupted. However, there is not enough information for us to figure out how it got into that state.
Is this a problem that is reproducible? If so, could you provide us with a journal (instructions here)? That would help us trace how/why/where the corruption happened.
Unfortunately I cannot put the journal file into a gist, so it has to be on my Google Drive which I hope is acceptable?
The crash is consistently reproducable when clicking on either of the orbiting vessels and does not occur when the vessel is landed. Also, a reinstall of Principia which I did after taking this journal did not fix the error.
I was able to reproduce the crash using the above journal, although things seem somewhat nondeterministic. No idea what's happening yet.
Decoded strack trace:
Lines 206 to 234 in de95343
Lines 356 to 382 in de95343
Lines 935 to 943 in de95343
Lines 396 to 458 in de95343
We have an empty segment (segment 472) in the middle of the trajectory for vessel
Sarnus II CF (Hermes I) Ship (15f6cf28-fc3e-4997-9ab4-93de951ab9c2). That's a violation of our invariants: empty segments are fine at the beginning of trajectories, not in the middle.
How did this come to be? This segment is the one immediately before the beginning of the "explicitly stored" part of the trajectory. We conjecture that it is non-collapsible, so it should be extracted from a checkpoint. However, there is no checkpoint matching the end time of that segment,
2000-10-24T16:27:13,1125793159008026 (TT) (that time falls between checkpoints 225 and 226). Normally we should always take a checkpoint when creating a non-collapsible segment, but there is worrisome code here:
Lines 195 to 218 in 5f93841
This is somewhat inconsistent, but wouldn't be a disaster if there wasn't a nasty interaction with
WriteToMessage: if given an iterator that designates a time at which a 1-point segment (or several) exists,
WriteToMessage skips these 1-point segments and starts writing at the first segment that has multiple points. The skipped 1-point segments will be reconstructed by integration (if they are collapsible) or from a checkpoint (if they are not). The problem here is that we don't have a checkpoint (because of the above code) so we have no way to reconstruct the missing segment.
Having written this I am not completely sure how it should be fixed. More thought will be needed...
|Issue Title||Created Date||Updated Date|