nil pointer dereference @ response.go:81

[seniorGolang]

After update:

panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x4 pc=0xc6974]

goroutine 34 [running]: panic(0x346eb0, 0x1070a038) /root/.gvm/gos/go1.6/src/runtime/panic.go:464 +0x330 sync/atomic.loadUint64(0x1080a1d4, 0x0, 0x0) /root/.gvm/gos/go1.6/src/sync/atomic/64bit_arm.go:10 +0x54 github.com/cavaliercoder/grab.(_Response).BytesTransferred(0x1080a180, 0x4, 0x386878) /root/.gvm/pkgsets/go1.6/global/src/github.com/cavaliercoder/grab/response.go:81 +0x40 github.com/cavaliercoder/grab.(_Client).do(0x107b79c0, 0x107f80f0, 0x0, 0x0, 0x0) /root/.gvm/pkgsets/go1.6/global/src/github.com/cavaliercoder/grab/client.go:222 +0x3c0 github.com/cavaliercoder/grab.(_Client).DoAsync.func1(0x107b79c0, 0x107f80f0, 0x10802380) /root/.gvm/pkgsets/go1.6/global/src/github.com/cavaliercoder/grab/client.go:94 +0x24 created by github.com/cavaliercoder/grab.(_Client).DoAsync /root/.gvm/pkgsets/go1.6/global/src/github.com/cavaliercoder/grab/client.go:102 +0x60

[cavaliercoder]

I'm having trouble reproducing this problem. Could you please provide some additional context on how to reproduce this problem?

The only pointer referenced in Response.BytesTransferred is c, which is a pointer to the Response itself, so the response is possibly be nil.

The previous call on the stack, client.go:222, calls resp.BytesTransferred() but it initialized resp itself and I don't see anywhere it could have been replace by nil in that function.

It is possible the nil pointer dereference actually occurred in the stdlib /root/.gvm/gos/go1.6/src/sync/atomic/64bit_arm.go:10. I see you are using Go 1.6. Could you please try and reproduce the issue with 1.5?

[seniorGolang]

This problem is present under the ARM. Example for Raspberry PI.

panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x4 pc=0xc4130]

goroutine 36 [running]: sync/atomic.loadUint64(0x106d8294, 0x0, 0x0) /root/.gvm/gos/go1.5.3/src/sync/atomic/64bit_arm.go:10 +0x54 github.com/cavaliercoder/grab.(_Response).BytesTransferred(0x106d8240, 0x4, 0x32ea50) /root/.gvm/pkgsets/go1.5.3/global/src/github.com/cavaliercoder/grab/response.go:81 +0x40 github.com/cavaliercoder/grab.(_Client).do(0x106709c0, 0x106d40f0, 0x10666540, 0x0, 0x0) /root/.gvm/pkgsets/go1.5.3/global/src/github.com/cavaliercoder/grab/client.go:222 +0x3c0 github.com/cavaliercoder/grab.(_Client).DoAsync.func1(0x106709c0, 0x106d40f0, 0x106c44c0) /root/.gvm/pkgsets/go1.5.3/global/src/github.com/cavaliercoder/grab/client.go:94 +0x24 created by github.com/cavaliercoder/grab.(_Client).DoAsync /root/.gvm/pkgsets/go1.5.3/global/src/github.com/cavaliercoder/grab/client.go:102 +0x60

[cavaliercoder]

That's why I can't reproduce it! There seems to be a known issue with alignment on ARM.

Please see:

• https://github.com/golang/go/issues/5278.
• https://golang.org/pkg/sync/atomic/#pkg-note-BUG

I'm not entirely sure how to manipulate alignment in Go... do you have any advice?

[luxas]

I think you should move doneFlag to the top of the struct

[cavaliercoder]

Could you please test this? I don't have access to any ARM processors to confirm the solution with. First PR wins.

Adding one Raspberry Pi to cart...

[seniorGolang]

Move bytesTransferred to the top of the struct Response solve the problem.

[cavaliercoder]

Replicated the issue on Win10 with Go v1.5 and v.16 by setting GOARCH=386 (as per #5)

[Elite]

So do we have a fix?

[cavaliercoder]

When I have a moment, I'm going to experiment with using mutexes instead of the atomic updates. I don't think that rearranging the alignment of the Response struct is the right fix as it will be difficult to lay it out in a clear ordered fashion, but more importantly, future changes to Response could break it again inadvertently.

[ohenepee]

Got the same error on Windows XP Pro SP3

So I'm anticipating that this problem has something to do with non-64-bit Windows OS builds