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]

On Wednesday, August 16, 2017 at 12:03:03 PM UTC+8, Björn Karge wrote:
>
> 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
>
>
> On Wednesday, August 16, 2017 at 12:41:47 AM UTC+8, Björn Karge 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?
>>
>>
>>
>> <https://www.grab.com/sg/work/?utm_source=Grab&utm_medium=email-signoff&utm_campaign=SG_GrabforWork&utm_term&utm_content>
>>  
>> *Grab is hiring. Learn more at **https://grab.careers 
>> <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.
>>
>
-- 
 
<https://www.grab.com/sg/work/?utm_source=Grab&utm_medium=email-signoff&utm_campaign=SG_GrabforWork&utm_term&utm_content>

-- 
*Grab is hiring. Learn more at **https://grab.careers 
<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.

Reply via email to