Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save-corruption crash: 0 < header_bits #2815

Closed
lpgagnon opened this issue Dec 8, 2020 · 4 comments
Closed

Save-corruption crash: 0 < header_bits #2815

lpgagnon opened this issue Dec 8, 2020 · 4 comments

Comments

@lpgagnon
Copy link

lpgagnon commented Dec 8, 2020

Originally seen a couple of days ago going from tracking station to a vessel; wasn't reproducible.
This time saw it quickloading from a vessel in flight to the same a few minutes earlier; reloading same career consistently crashes during load.
(I'm assuming it's the same issue based on the same failed check)

Logs attached are for the initial quickload crash, the only one with a chance of having clues how the corruption crept in. Still no known way to trigger the root problem, so journal unlikely.

Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    @   00007FFCE2026360  	google::LogMessageFatal::~LogMessageFatal [0x00007FFCE202635F+47]
    @   00007FFCA90D40BD  	(No symbol) [0x00007FFCA90D40BC]
    @   00007FFCA91A8F0B  	principia__VesselVelocity [0x00007FFCA91A8F0A+76762]
    @   00007FFCA91A5B8C  	principia__VesselVelocity [0x00007FFCA91A5B8B+63579]
    @   00007FFCA92E5B0B  	principia__VesselVelocity [0x00007FFCA92E5B0A+1374170]
    @   00007FFCA92B7C66  	principia__VesselVelocity [0x00007FFCA92B7C65+1186101]
    @   00007FFCA9162762  	(No symbol) [0x00007FFCA9162761]
    @   00007FFCA912CE3F  	(No symbol) [0x00007FFCA912CE3E]
    @   00007FFCA9116612  	(No symbol) [0x00007FFCA9116611]
    @   00007FFD031D10B2  	beginthreadex [0x00007FFD031D10B1+321]
    @   00007FFD042A7C24  	BaseThreadInitThunk [0x00007FFD042A7C23+19]
    @   00007FFD0602D4D1  	RtlUserThreadStart [0x00007FFD0602D4D0+32]
F1207 22:23:49.782630 14872 zfp_compressor.cpp:57] Check failed: 0 < header_bits (0 vs. 0) 

logs

As with the other corruption crash, I can provide .sfs, but seems unlikely to contain much helpful, corruption has already happened.

@lpgagnon
Copy link
Author

lpgagnon commented Dec 8, 2020

happened again an hour or so later. feels like it's getting worse. Still no pattern that I can see

@pleroy
Copy link
Member

pleroy commented Jan 19, 2021

If you still have the save and could post it, I would take a look. This one is even weirder than #2796: the Gipfeli decompression worked, but zfp thinks that the header is missing. So Gipfeli liked the bits that it saw (it particular, the length) but the payload seems to be corrupted.

@lpgagnon
Copy link
Author

Turns out I did keep it around. https://drive.google.com/file/d/1EABDmIX0_44UBZzXWUsO6w_dwfPuoicH/view?usp=sharing

fwiw, I don't think it happened again after my last comment.

@pleroy
Copy link
Member

pleroy commented Feb 1, 2021

Not surprisingly, I don't have a clue. We are in the process of decompressing (using zfp) a large string (12 056 024 bytes) containing the history of vessel 0164 photo 4-2, guid 993863e5-255b-4a73-8863-7abc918f86d9. We successfully decompress the t component (-1 257 529 709.172 721 6 s to -1 167 631 295.835 333 6s, spanning 34 months) and the qx component. Then when we come to qy we do not find the "zfp" string that indicates a header. The funny thing is that the last values for qx look believable, although of course this may be an artifact of the compression method.

I am recording this for posterity in case the same problem crops up again. I am closing the issue because I can't see a way to make progress without more data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants