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

nextByte: insufficient buffer (24 of 23) #147

Open
darrensapalo opened this issue Jan 8, 2023 · 2 comments
Open

nextByte: insufficient buffer (24 of 23) #147

darrensapalo opened this issue Jan 8, 2023 · 2 comments

Comments

@darrensapalo
Copy link

darrensapalo commented Jan 8, 2023

Summary

I'm receiving the error below when parsing newer DotA 2 match replays.

nextByte: insufficient buffer (24 of 23)

Hypothesis

This might be related to patch changes affecting the packet rules/version, because attempting to patch it using older matches works successfully. These parsing errors appear to occur for matches beyond December 2022. This is based on an estimate and imprecise testing. My replays before November 2022 are able to be parsed properly.

Example demo match replay Match ID: 6955604251

Unfortunately, GitHub doesn't allow .dem uploads.

Screenshots

Debugger shows the following error is thrown, but I've tried googling what library (standard?) is throwing it but I'm unable to find it.

image

@darrensapalo
Copy link
Author

This is likely related to protobuf definitions changing. I tried to use an alternative parser (i.e. clarity) but then it also encountered parsing issues.

I hypothesize that it must be the same- the low level parser owners need to update their protobuf definitions given the steam update sometime September/December 2022.

@brunal
Copy link

brunal commented Feb 6, 2023

I've tried googling what library (standard?) is throwing it but I'm unable to find it.

It's from reader.go. Either here or there.

It's trying to read more bytes than are available.

The issue is that by being a panic and not a simple error, we cannot get the chain of explanations that brought the program to this situation.

You can, however, use the runtime/debug package to recover from the panic to write its stack trace: https://stackoverflow.com/a/52106370.

Can you share it? That should help. The alternative would be to make nextByte return an error & handle that, but it's more toil dev-wise.

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