memmove receives NULL src and positive length?

[bjorn...@grabtaxi.com]

Hello!

I got this panic trace which I am trying to get my head around:

panic: runtime error: invalid memory address or nil pointer dereference  

[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x45c3d2]  

message=‘’ •••    

goroutine 6786902223 [running]:  

panic(0xc03040, 0x116d2f0)  

    golang/go/src/runtime/panic.go:531 +0x1cf fp=0xc47d406d90 sp=0xc47d406cf8  

runtime.panicmem()  

    golang/go/src/runtime/panic.go:63 +0x5e fp=0xc47d406db0 sp=0xc47d406d90  

runtime.sigpanic()  

    golang/go/src/runtime/signal_unix.go:290 +0x29f fp=0xc47d406e00 sp=0xc47d406db0  

runtime.memmove(0xc44f8e4500, 0x0, 0x18)  

    golang/go/src/runtime/memmove_amd64.s:178 +0x682 fp=0xc47d406e08 sp=0xc47d406e00  our/source/code.glob..func5.1(0x0, 0x3, 0x3, 0xc43104d380, 0xc436f05900, 0x73, 0xc47bd2e8a0, 0x24, 0xc437f1d616, 0x6, ...)  

    /our/source/code.go:123 +0xa2 fp=0xc47d406f58 sp=0xc47d406e08  

runtime.goexit()  

    golang/go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc47d406f60 sp=0xc47d406f58  

created by our/source/code.glob..func5  

    /our/source/code.go:132 +0x150 

Here's the stripped-down source code fragment (our/source/code.go with relevant line numbers added)

var f = func(a A, b, c string, src []int64, d string, e, f string, g []byte) chan error {
   ec := make(chan error, somepkg.Count())

   go func(a A) {
      dest := make([]int64, len(src))
123:  copy(dest, src)

      defer close(ec)
      ...

      defer something()
      ...

132:}(a)

   return ec
}

At first, this looks like an OOM as it seems to be triggered by a copy to a freshly allocated array (dest := make([]int64, len(src)) + copy(dest, src)). But at closer inspection memmove(0xc44f8e4500, 0x0, 0x18) seems to indicate that the source is 0 (the second parameter if we trust memmove_amd64.s). In that case, how could the length (0x18) have been determined in the first place?

Put differently, how can ptr of a slice (as in https://blog.golang.org/go-slices-usage-and-internals) be a null pointer when the slice has a length? Does this indicate a missed check of malloc (or however the equivalent is called in the go runtime env)? Or am I misunderstanding the trace?

Grab is hiring. Learn more at https://grab.careers

By communicating with Grab Inc and/or its subsidiaries, associate companies and jointly controlled entities (“Grab Group”), you are deemed to have consented to processing of your personal data as set out in the Privacy Notice which can be viewed at https://grab.com/privacy/

This email contains confidential information and is only for the intended recipient(s). If you are not the intended recipient(s), please do not disseminate, distribute or copy this email and notify Grab Group immediately if you have received this by mistake and delete this email from your system. Email transmission cannot be guaranteed to be secure or error-free as any information therein could be intercepted, corrupted, lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do not accept liability for any errors or omissions in the contents of this email arises as a result of email transmission. All intellectual property rights in this email and attachments therein shall remain vested in Grab Group, unless otherwise provided by law.

[Jakob Borg]

Have you run this code by the race detector?

> Grab is hiring. Learn more at https://grab.careers
>
> By communicating with Grab Inc and/or its subsidiaries, associate companies and jointly controlled entities (“Grab Group”), you are deemed to have consented to processing of your personal data as set out in the Privacy Notice which can be viewed at https://grab.com/privacy/
>
> This email contains confidential information and is only for the intended recipient(s). If you are not the intended recipient(s), please do not disseminate, distribute or copy this email and notify Grab Group immediately if you have received this by mistake and delete this email from your system. Email transmission cannot be guaranteed to be secure or error-free as any information therein could be intercepted, corrupted, lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do not accept liability for any errors or omissions in the contents of this email arises as a result of email transmission. All intellectual property rights in this email and attachments therein shall remain vested in Grab Group, unless otherwise provided by law.
>

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Björn Karge]

Jakob, thanks for your suggestion - it lifted me out of the too narrow context :-)

The reason seems to be that src is already corrupt when arriving at f() because of a data race (between go routines GR1, GR2 below), copying a slice during (non-atomic) assignment.
The null pointer is probably placed by go in the course of the slice assignment in order to fail fast and avoid buffer overruns during data races.

obj.data : [0x1c28374,2,3]

GR1> { obj.data := newData [Step X] }

obj.data : [0x0,2,3]

GR2> { f(…, src:[0x0,2,3],…) }

GR1> { obj.data:= newData [Step X+N] }

obj.data : [0x2349231,4,4]

Cheers!

Björn

[Björn Karge]

Just a minor correction:

go tool objdump showed that golang does not touch the pointer value before overwriting it.

The situation does occur nevertheless because obj.data may be nil [0x0,0,0] initially, and length/capacity are assigned before the data pointer is set:

obj.data : [0x0,0,0]

GR1> { obj.data := newData [Step X] }

obj.data : [0x0,4,4]

GR2> { f(…, src:[0x0,4,4],…) }

GR1> { obj.data:= newData [Step X+N] }

obj.data : [0x2349231,4,4]