String with nil backing array causing panics in 1.23 #69710
Comments
|
cc @golang/runtime |
Can you share the stacktrace when you met the error with the Also, can you share more details about how |
seankhliao
added
the
WaitingForInfo
|
Have you run your application under the race detector ( The size in question is 0x10000010003. Makes me think of #68227 which was a missing zero extension on arm64. |
|
Stack trace when we used built-in json marshaller: The When we create a new Contrary to what I said above, we think we've now been able to recreate it with a 1.22 build. However, it manifested slightly differently with a |
We haven't run it under the race detector. At the moment we're only seeing the issue on Windows / amd64 (although we're generally using mac arm64 as a development environment). That said, I noticed that the size looked "structured" rather than random and indeed we have seen the same value multiple times (I can't be definitive that it was always the same) |
|
I have now realised, partly with the prompt from @randall77 , that if Is there anything useful we can look for in the executable to help track down the situation where this issue might be coming from? Unfortunately I can't share the executable itself (and it's about 140MB) |
|
Please run with the race detector if you can. Heap corruption like this (if that's what it is) is easily caused by data races. |
Thanks. We will do that (probably tomorrow UK time as we've lost our connection to the customer's environment for the day). Thanks for your help. |
|
Based on today's investigations it seems most likely that this is a race condition leading to corruption. My team and I very much appreciate the rapid responses and guidance given! |
Go version
go1.23.1 windows/amd64
Output of
go envin your module/workspace:What did you do?
We have a large complex code base and are still tracking down the issue. Code that has been running fine on go1.22 seems to be failing on go1.23. At the moment we haven't been able to recreate the issue except on a customer system.
What did you see happen?
We noticed that when requesting the length of a string variable, we were getting a size > 1TB. On closer inspection it appears that the data pointer for the string is nil and there is (we assume) invalid data in the length property).
The string in question may be being created programmatically, or may be coming as the result of unmarshalling JSON into an object (we initially suspected the unmarshalling library, but we switched this out for the standard-library version and saw the same results). We are continuing to try and isolate where the invalid string is being created.
It's worth noting that this appears to have a degree of randomness to it, in that we can sometimes have a run which doesn't exhibit the issue - also the code path where we're having the issue is executed thousands of times during a run and many of those times are successful before we see a failure.
We are getting a strack trace as follows (only partial I'm afraid):
The code at /go/pkg/mod/scm.company.local/project/project.git@v0.26.1-0.20240930081403-908ad04ce8ae/data/node.go:46 is as follows:
What did you expect to see?
We expected it to run the same on version 1.23 as on version 1.22.
As we are still trying to track this down, if there are additional things we could try (or try to eliminate) that would be helpful.
We are somewhat at a loss as to how the string could get a nil backing array (we're not doing anything with unsafe pointers etc in our code base).
The text was updated successfully, but these errors were encountered: