Have you run this code by the race detector?
On 15 Aug 2017, at 17:01, bjorn.karge via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> 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.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
