-
Notifications
You must be signed in to change notification settings - Fork 17.4k
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
internal/poll: panic: runtime error: slice bounds out of range [xx:30] #66755
Comments
I see that the byte slice being written is allocated by a buffer pool. https://github.com/syncthing/syncthing/blob/main/lib/protocol/bufferpool.go Without digging super deep into this code, I suspect that it's not concurrent safe. Does the race detector report anything? |
This has been stress tested with the race detector quite extensively over the years, without anything popping up. I also hammered it as much as I could before filing as I had the same suspicion. :) As mentioned it never shows up on other platforms than darwin. And in any case the slice that gets written after passing through TLS should be somewhat different from the slice passed into TLS? |
This is probably a dup of #61060. In particular, it feels like the system write is returning an invalid result (one longer than the amount we asked it to write). |
Ah yes, looks like the same issue, thanks. |
Go version
go1.22.2 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
Syncthing gathers crash reports from users, when the binary panics or otherwise exits abnormally for some reason. There's a lot of very mysterious stuff in there, which we'll often attribute to system/hardware problems of some kind if it's not systematic. However, there is one thing that is systematic and has existed for years now (at least back to Go 1.19) with the same backtrace.
I'm posting this here not because I have an obvious smoking gun, but to see if it makes sense to anyone familiar with the internals in question...
What did you see happen?
Essentially, this:
Things I note here:
30
, but not precisely always. The start index is always higher than 30.Examples of other indexes:
What did you expect to see?
The slice passed should be fine... Especially, since the slice with the impossible indexes is after TLS has done it's thing. My gut feeling is there are shenanigans in the TLS stack on Darwin...?
The text was updated successfully, but these errors were encountered: