Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/cgo: false 'cgo argument has Go pointer to Go pointer when using Go 1.6' report #13934

Closed
napsy opened this issue Jan 13, 2016 · 16 comments

Comments

@napsy
Copy link

commented Jan 13, 2016

It seems that the Go runtime reports an error, stating:

cgo argument has Go pointer to Go pointer

The offending code is

package main

import (
    zmq "github.com/pebbe/zmq4"
    msgpack "gopkg.in/vmihailenco/msgpack.v2"

    "fmt"
    "log"
)

func main() {

    pub, err := zmq.NewSocket(zmq.PUB)
    if err != nil {
        log.Fatal(err)
    }
    err = pub.Bind("tcp://127.0.0.1:9997")
    if err != nil {
        log.Fatal(err)
    }

    data, err := msgpack.Marshal(map[string]string{"hello": "world"})
    if err != nil {
        log.Fatal(err)
    }
    // uncommenting the next line makes the panic disappear
    //data = []byte("\x81\xa5hello\xa5world")

    parts := [][]byte{[]byte("aRoute"), data}

    n, err := pub.SendMessage(parts)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(n)
}

As seen from a bug report for zmq4, the author didn't get the runtime panic when running the same code using Go 1.6

Go version: 1.6 beta1
OS/Platform: Ubuntu 15.10 linux/amd64

@kostix

This comment has been minimized.

Copy link

commented Jan 13, 2016

Do I assume correctly that atfter a call to

data, err := msgpack.Marshal(map[string]string{"hello": "world"})

the data variable contains the value

[]byte("\x81\xa5hello\xa5world")

?

@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Jan 13, 2016

@ianlancetaylor ianlancetaylor changed the title False 'cgo argument has Go pointer to Go pointer when using Go 1.6' report cmd/cgo: false 'cgo argument has Go pointer to Go pointer when using Go 1.6' report Jan 13, 2016

@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

That's correct

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

Please set the environment variable GOTRACEBACK=2 and show us the full stack trace.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

Actually, I suspect this is fixed by https://golang.org/cl/18391, which I think was not in Go 1.6 beta1. Can you try tip?

@ianlancetaylor ianlancetaylor self-assigned this Jan 13, 2016

@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

It's the same using tip:

GOTRACEBACK=2 go run test.go

panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running]:
runtime.gopanic(0x539180, 0xc82000a790)
    /home/napsy/go/src/runtime/panic.go:464 +0x3e6 fp=0xc820049800 sp=0xc820049780
runtime.cgoCheckUnknownPointer(0xc820054094, 0x5973e0, 0x29)
    /home/napsy/go/src/runtime/cgocall.go:524 +0x288 fp=0xc8200498b8 sp=0xc820049800
runtime.cgoCheckArg(0x506300, 0xc820054094, 0xc820000100, 0x5973e0, 0x29)
    /home/napsy/go/src/runtime/cgocall.go:494 +0x55f fp=0xc8200499b0 sp=0xc8200498b8
runtime.cgoCheckPointer(0x506300, 0xc820054094, 0x0, 0x0, 0x0, 0x0, 0x0)
    /home/napsy/go/src/runtime/cgocall.go:391 +0xc2 fp=0xc820049a00 sp=0xc8200499b0
github.com/pebbe/zmq4._cgoCheckPointer0(0x506300, 0xc820054094, 0x0, 0x0, 0x0, 0xc4ff10)
    ??:0 +0x4d fp=0xc820049a50 sp=0xc820049a00
github.com/pebbe/zmq4.(*Socket).SendBytes(0xc8200126f0, 0xc820054094, 0xd, 0x40, 0x0, 0x6, 0x0, 0x0)
    /home/napsy/git/koala2/src/github.com/pebbe/zmq4/zmq4.go:769 +0x16b fp=0xc820049b10 sp=0xc820049a50
github.com/pebbe/zmq4.(*Socket).sendMessage(0xc8200126f0, 0x0, 0xc820049e70, 0x1, 0x1, 0x6, 0x0, 0x0)
    /home/napsy/git/koala2/src/github.com/pebbe/zmq4/utils.go:66 +0x4b4 fp=0xc820049d90 sp=0xc820049b10
github.com/pebbe/zmq4.(*Socket).SendMessage(0xc8200126f0, 0xc820049e70, 0x1, 0x1, 0xc82000e460, 0x0, 0x0)
    /home/napsy/git/koala2/src/github.com/pebbe/zmq4/utils.go:18 +0x56 fp=0xc820049dd8 sp=0xc820049d90
main.main()
    /home/napsy/git/koala2/test.go:29 +0x622 fp=0xc820049f50 sp=0xc820049dd8
runtime.main()
    /home/napsy/go/src/runtime/proc.go:188 +0x2b0 fp=0xc820049fa0 sp=0xc820049f50
runtime.goexit()
    /home/napsy/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc820049fa8 sp=0xc820049fa0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /home/napsy/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc820038fb8 sp=0xc820038fb0

goroutine 2 [force gc (idle)]:
runtime.gopark(0x5a7730, 0x833b40, 0x56d460, 0xf, 0x14, 0x1)
    /home/napsy/go/src/runtime/proc.go:262 +0x163 fp=0xc820024758 sp=0xc820024730
runtime.goparkunlock(0x833b40, 0x56d460, 0xf, 0xc820000114, 0x1)
    /home/napsy/go/src/runtime/proc.go:268 +0x54 fp=0xc820024790 sp=0xc820024758
runtime.forcegchelper()
    /home/napsy/go/src/runtime/proc.go:229 +0xb8 fp=0xc8200247c0 sp=0xc820024790
runtime.goexit()
    /home/napsy/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc8200247c8 sp=0xc8200247c0
created by runtime.init.4
    /home/napsy/go/src/runtime/proc.go:218 +0x2b

goroutine 3 [GC sweep wait]:
runtime.gopark(0x5a7730, 0x833c60, 0x56aba0, 0xd, 0x420414, 0x1)
    /home/napsy/go/src/runtime/proc.go:262 +0x163 fp=0xc820024f48 sp=0xc820024f20
runtime.goparkunlock(0x833c60, 0x56aba0, 0xd, 0x14, 0x1)
    /home/napsy/go/src/runtime/proc.go:268 +0x54 fp=0xc820024f80 sp=0xc820024f48
runtime.bgsweep(0xc820054000)
    /home/napsy/go/src/runtime/mgcsweep.go:63 +0xb1 fp=0xc820024fb8 sp=0xc820024f80
runtime.goexit()
    /home/napsy/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc820024fc0 sp=0xc820024fb8
created by runtime.gcenable
    /home/napsy/go/src/runtime/mgc.go:191 +0x53

goroutine 4 [finalizer wait]:
runtime.gopark(0x5a7730, 0x84e308, 0x56d1a0, 0xe, 0x14, 0x1)
    /home/napsy/go/src/runtime/proc.go:262 +0x163 fp=0xc820025718 sp=0xc8200256f0
runtime.goparkunlock(0x84e308, 0x56d1a0, 0xe, 0x14, 0x1)
    /home/napsy/go/src/runtime/proc.go:268 +0x54 fp=0xc820025750 sp=0xc820025718
runtime.runfinq()
    /home/napsy/go/src/runtime/mfinal.go:158 +0xaa fp=0xc8200257c0 sp=0xc820025750
runtime.goexit()
    /home/napsy/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc8200257c8 sp=0xc8200257c0
created by runtime.createfing
    /home/napsy/go/src/runtime/mfinal.go:139 +0x60
exit status 2

Go version:

$ go version
go version devel +f3ce054 Wed Jan 13 15:14:04 2016 +0000 linux/amd64
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

It really looks for all the world like you are still running the old code somehow.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

Please try this program on the version of go you have crashing:

package main

/*
void f(void *x) { }
*/
import "C"

import (
    "bytes"
    "unsafe"
)

func main() {
    b := &new([2]bytes.Buffer)[1]
    b.WriteString("hello world")
    data := b.Bytes()
    C.f(unsafe.Pointer(&data[0]))
    println(b, &data[0])
}
@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

The code above produces the following output:

GOTRACEBACK=2 go run test2.go                                                                                   *[develop] 
0xc82007a070 0xc82007a094

I did a git pull on the go source tree and recompiled:

go version devel +4525571 Wed Jan 13 17:48:41 2016 +0000 linux/amd64

And repeated my previous failing test and the results are the same, the program panics.

@gopherbot

This comment has been minimized.

Copy link

commented Jan 13, 2016

CL https://golang.org/cl/18612 mentions this issue.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

What version of the github.com/pebbe/zmq4 package are you using? The line numbers don't correspond to the code I see when I go get github.com/pebbe/zmq4.

@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

I use the master branch (commit 1c9da3d). I use git subtree for dependency management in my project and don't use go get.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

This line in your stack trace:

github.com/pebbe/zmq4._cgoCheckPointer0(0x506300, 0xc820054094, 0x0, 0x0, 0x0, 0xc4ff10)

corresponds to the second call to _cgoCheckPointer0 in this code in generated by cmd/cgo:

size, err := _C2func_zmq_send(_cgoCheckPointer0(soc.soc), _cgoCheckPointer0(unsafe.Pointer(&d[0]), d), _Ctype_size_t(len(data)), _Ctype_int(flags))

But that does not make sense, as the stack trace shows that the value d is being passed as an empty slice, when we can see from the earlier call in the stack trace, and from the fact that the code did not panic, that the slice is not empty.

Please run go build -work github.com/pebbe/zmq4. That will create a directory /tmp/go-buildNNNN. Look at /tmp/go-buildNNNN/github.com/pebbe/zmq4/_obj/zmq4.cgo1.go. Look for the SendBytes method. What does the generated code for that method look like?

Thanks.

@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

It looks like this:

//line /home/napsy/git/koala2/src/github.com/pebbe/zmq4/zmq4.go:759
func (soc *Socket) SendBytes(data []byte, flags Flag) (int, error) {
    if !soc.opened {
        return 0, ErrorSocketClosed
    }
    d := data
    if len(data) == 0 {
        d = []byte{0}
    }
//line /home/napsy/git/koala2/src/github.com/pebbe/zmq4/zmq4.go:769

//line /home/napsy/git/koala2/src/github.com/pebbe/zmq4/zmq4.go:768
    hdr := (*reflect.SliceHeader)(unsafe.Pointer(&d))
                                    size, err := _C2func_zmq_send(_cgoCheckPointer0(soc.soc), _cgoCheckPointer0(unsafe.Pointer(hdr.Data)),           _Ctype_size_t(len(data)), _Ctype_int(flags))
                                    if size < 0 {
        return int(size), errget(err)
    }
    return int(size), nil
}
@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

The hdr was my work to try other methods of passing the slice, but if I revert tot the original master it still fails

@napsy

This comment has been minimized.

Copy link
Author

commented Jan 13, 2016

Oh well, turns out it works now. I did a clean zmq pull and it works now

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

For the future, reflect.SliceHeader is never the right answer.

I'm glad it is working now. I will close this bug report, but please reopen if you find some other issue.

gopherbot pushed a commit that referenced this issue Jan 13, 2016
runtime: arrange to show a few local variables when cgoCheckUnknownPo…
…inter panics

For #13934.

Change-Id: Id399e35598def96f8bb89b9fcd1bf14ee06e2e62
Reviewed-on: https://go-review.googlesource.com/18612
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

@golang golang locked and limited conversation to collaborators Jan 13, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.