panic: nil dereference in autogenerated hash function

[Shivaram Lingamneni]

I'm seeing the following panic on both Go 1.20.7 and Go 1.21.0 (amd64):

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x46e421]
goroutine 368 [running]:
type:.hash.redacted.com/redacted/redacted.componentKey(0xc001b37de8, 0xc001b37d68?)
<autogenerated>:1 +0x2c
redacted.com/redacted/redacted.(*redactedType[...]).redactedMethod1(0x1481900, 0xc0046c6a20)
redacted/redacted.go:182 +0x2c5
redacted.com/redacted/redacted.(*redactedType[...]).redactedMethod2(0x1481900)
redacted/redacted.go:141 +0x5c
created by redacted.com/redacted.NewRedactedType[...] in goroutine 1
redacted/redacted.go:99 +0x165

componentKey is:

type componentKey struct {
a string
b string
}

Line 182 is:

myMap[myComponentKey] += 1

where myMap is of type map[componentKey]int64, and myComponentKey is of type componentKey.

As I understand it:

1. The issue is not that myMap is nil; if that were the case, the panic would read `assignment to entry in nil map`
2. The nil dereference is coming from the hash function that the compiler autogenerated for componentKey, which looks something like this (Go 1.21):

TEXT type:.hash.main.componentKey(SB) <autogenerated>
  <autogenerated>:1     0x457780                493b6610                CMPQ SP, 0x10(R14)
  <autogenerated>:1     0x457784                762c                    JBE 0x4577b2
  <autogenerated>:1     0x457786                55                      PUSHQ BP
  <autogenerated>:1     0x457787                4889e5                  MOVQ SP, BP
  <autogenerated>:1     0x45778a                4883ec10                SUBQ $0x10, SP
  <autogenerated>:1     0x45778e                4889442420              MOVQ AX, 0x20(SP)
  <autogenerated>:1     0x457793                e808d0ffff              CALL runtime.strhash(SB)
  <autogenerated>:1     0x457798                488b4c2420              MOVQ 0x20(SP), CX
  <autogenerated>:1     0x45779d                4883c110                ADDQ $0x10, CX
  <autogenerated>:1     0x4577a1                4889c3                  MOVQ AX, BX
  <autogenerated>:1     0x4577a4                4889c8                  MOVQ CX, AX
  <autogenerated>:1     0x4577a7                e8f4cfffff              CALL runtime.strhash(SB)
  <autogenerated>:1     0x4577ac                4883c410                ADDQ $0x10, SP
  <autogenerated>:1     0x4577b0                5d                      POPQ BP
  <autogenerated>:1     0x4577b1                c3                      RET
  <autogenerated>:1     0x4577b2                4889442408              MOVQ AX, 0x8(SP)
  <autogenerated>:1     0x4577b7                48895c2410              MOVQ BX, 0x10(SP)
  <autogenerated>:1     0x4577bc                0f1f4000                NOPL 0(AX)
  <autogenerated>:1     0x4577c0                e8fbcdffff              CALL runtime.morestack_noctxt.abi0(SB)
  <autogenerated>:1     0x4577c5                488b442408              MOVQ 0x8(SP), AX
  <autogenerated>:1     0x4577ca                488b5c2410              MOVQ 0x10(SP), BX
  <autogenerated>:1     0x4577cf                ebaf                    JMP type:.hash.main.componentKey(SB)

I'm having difficulty understanding how this code could produce a nil dereference, unless some runtime assumptions are being violated (maybe the string pointer and length are out of sync due to a data race)?

Thanks very much for your time.

[Ian Lance Taylor]

On Fri, Sep 22, 2023 at 9:15 AM Shivaram Lingamneni
<shivaraml...@gmail.com> wrote:
>
> I'm having difficulty understanding how this code could produce a nil dereference, unless some runtime assumptions are being violated (maybe the string pointer and length are out of sync due to a data race)?

I agree: this looks like some form of memory corruption. Run the code
under the race detector. Look closely at any uses of cgo or the
unsafe package.

Ian