Bad backtraces because codeloc compression does not roundtrip properly #54031
Comments
Keno
added a commit
that referenced
this issue
Apr 11, 2024
I'm not entirely sure what the original intent of this statement was, but the effect ends up being that some codeloc entries end up negative in the compressed representation, but the code always assumes unsigned integers, so things roundtripped badly, leading to badly corrupted stack traces. Fixes #54031.
|
I wonder if this is the issue behind #53816 and that the libunwind warning is a red herring |
|
Try the PR and see if the issue is fixed. |
Keno
added a commit
that referenced
this issue
Apr 11, 2024
I'm not entirely sure what the original intent of this statement was, but the effect ends up being that some codeloc entries end up negative in the compressed representation, but the code always assumes unsigned integers, so things roundtripped badly, leading to badly corrupted stack traces. I guess this might have been a rebase mistake, since the same line exists (correctly) a few lines prior. Fixes #54031.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been noticing completely garbage backtraces in longer functions. I've looked into this a bit, and I believe the root cause is that
codelocsdon't roundtrip properly through the compression. E.g. here is the linetable from one of my larger functions, which comes out garbage from decompression: https://gist.github.com/Keno/0a5a9d90427f8352c5f9bf1ce394a998The text was updated successfully, but these errors were encountered: