Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign updelta and doubleDelta chunks should be created with minimum length so that data corruption can be handled more gracefully #1653
Comments
brian-brazil
added
the
kind/bug
label
May 24, 2016
This comment has been minimized.
This comment has been minimized.
|
That looks like data corruption alright. @beorn7 |
This comment has been minimized.
This comment has been minimized.
|
There's a good chance that the disk this was on filled up at some point, which we are aware of as the only currently known source of data corruption. |
This comment has been minimized.
This comment has been minimized.
|
Yes, this is definitely data corruption. I have an idea why it is not handled more gracefully. I'll change the title accordingly. |
beorn7
self-assigned this
May 24, 2016
beorn7
changed the title
Slice bounds out of range panic while viewing graph
delta and doubleDelta chunks should be created with minimum length so that data corruption can be handled more gracefully
May 24, 2016
This comment has been minimized.
This comment has been minimized.
|
Essentially: The used part of a delta or double-delta chunk is encoded in the chunk itself. If that part is corrupted, a chunk may be created that doesn't even have use enough of its (fixed) 1k length that the header fit in completely. Access to header fields can then lead to the kind of panic reported here. solution is easy: create chunks with a minimum length, or quarantine the series anyway if a chunk is found that claims to be shorter than possible. |
dmilstein
referenced this issue
Aug 25, 2016
Merged
Catch errors when unmarshalling delta/doubleDelta encoded chunks #1923
dmilstein
added a commit
to dmilstein/prometheus
that referenced
this issue
Aug 30, 2016
beorn7
closed this
Aug 30, 2016
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 24, 2019
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
CrawX commentedMay 24, 2016
•
edited by brian-brazil
I just got the following slice bounds out of range panic while viewing a graph that has previously worked without problems. I'm using the official 0.18.0 build (linux amd64) available from the release page.
I'm guessing this is irrelevant but the query I'm executing is
label_replace(sum(archive_bytes_written{node="archiving1"}) by (archivename), "archivename_short", "$1$2", "archivename","(standard)|archive-instance-(.*)")I manually replaced \n and \t with actual \n and \t in the ouput. Github doesn't format the backtrace too well though so you can also find it here http://pastebin.com/Qj31Qz8W.
I suspect that there is some kind of file corruption here but I assume this should not lead to a panic.