Have you tried running the code with the race detector enabled? I suspect that you are concurrently modifying `u.memoize.str` by calling `u.String()` from multiple goroutines. And the non-zero length of the string header written by one goroutine becomes visible to the other one, before the modification to the data pointer.
On Fri, Mar 15, 2024 at 11:15 PM Ethan Reesor <ethan.ree...@gmail.com> wrote: > From this CI job > <https://gitlab.com/accumulatenetwork/accumulate/-/jobs/6398114923>: > > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x51d8b7] > goroutine 1589381 [running]: > strings.EqualFold({0xc000beec20?, 0x0?}, {0x0?, 0xacace7?}) > /usr/local/go/src/strings/strings.go:1111 +0x37 > gitlab.com/accumulatenetwork/accumulate/pkg/url.(*URL).Equal(0xc000a74e40?, > 0xc00094c540) > /builds/accumulatenetwork/accumulate/pkg/url/url.go:472 +0x10c > > This is in a docker container based on the go:1.22 image, so the panic > appears to be happening here: > > func EqualFold(s, t string) bool { > // ASCII fast path > i := 0 > for ; i < len(s) && i < len(t); i++ { > sr := s[i] > tr := t[i] // <-- line 1111 > > (*URL).Equal > <https://gitlab.com/accumulatenetwork/accumulate/-/blob/5b1cb612d76d4163a101303e51a6fd352224cdab/pkg/url/url.go#L465> > : > > func (u *URL) Equal(v *URL) bool { > if u == v { > return true > } > if u == nil || v == nil { > return false > } > return strings.EqualFold(u.String(), v.String()) > } > > (*URL).String > <https://gitlab.com/accumulatenetwork/accumulate/-/blob/5b1cb612d76d4163a101303e51a6fd352224cdab/pkg/url/url.go#L240> > : > > func (u *URL) String() string { > if u.memoize.str != "" { > return u.memoize.str > } > > u.memoize.str = u.format(nil, true) > return u.memoize.str > } > > (*URL).format > <https://gitlab.com/accumulatenetwork/accumulate/-/blob/5b1cb612d76d4163a101303e51a6fd352224cdab/pkg/url/url.go#L189> > : > > func (u *URL) format(txid []byte, encode bool) string { > var buf strings.Builder > // ... write to the builder > return buf.String() > } > > How is this possible? Based on `addr=0x0` in the panic I think this is a > nil pointer panic, as opposed to some other kind of segfault. The only way > I can reproduce panic-on-string-index is with > `(*reflect.StringHeader)(unsafe.Pointer(&s)).Data > = 0`, but I don't see how that can be happening here. I'm saving the string > but I'm not doing anything weird with it. And the string header is a value > type so code that manipulates the returned string shouldn't modify the > original. And I'm definitely not doing any kind of unsafe string > manipulation like that in my code, anywhere. The only reference to unsafe > anywhere in my code is for parameters for calling GetDiskFreeSpaceExW > (Windows kernel32.dll call). > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d6f6bb75-45e9-4a38-9bbd-d332e7f3e57cn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d6f6bb75-45e9-4a38-9bbd-d332e7f3e57cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGnvZ1NAAp7U93HqjRu5kpRmD6A2DEwiYtPNN9muuWx9Q%40mail.gmail.com.
