Simultaneous execution of CGO calls?

[Peter Kleiweg]

I had a weird crash in a program: fatal error: unexpected signal during runtime execution

This was when C code was being called that has worked a long time without problems.

Here is a fragment of the dump:

    goroutine 1342 [syscall, locked to thread]:

    runtime.cgocall(0x83d120, 0xc820654be8, 0x0)

            /net/aps/64/opt/go/src/runtime/cgocall.go:123 +0x11b fp=0xc820654bb0 sp=0xc820654b80

    main._Cfunc_makeGraph(0x7f7204001830, 0x0)

            _/net/aistaff/kleiweg/paqu/src/pqserve/_obj/_cgo_gotypes.go:77 +0x3e fp=0xc820654be8 sp=0xc820654bb0

    main.tree(0xc8200c68f0)

            /net/aistaff/kleiweg/paqu/src/pqserve/tree.go:376 +0x1bba fp=0xc820655398 sp=0xc820654be8

And here another:

    goroutine 1343 [runnable]:

    net/http.(*response).Write(0xc82033c000, 0xc8204e6000, 0x79, 0xe0, 0x900000, 0x992c80, 0xc820415000)

            /net/aps/64/opt/go/src/net/http/server.go:1208

    fmt.Fprint(0x7f721cb93cb0, 0xc82033c000, 0xc820415060, 0x1, 0x1, 0x11, 0x0, 0x0)

            /net/aps/64/opt/go/src/fmt/print.go:223 +0xa5

    main.tree(0xc82033c410)

            /net/aistaff/kleiweg/paqu/src/pqserve/tree.go:416 +0x2680

So, two goroutines are working executing code from tree.go, which calls C like this:

    s1 := C.myfunc(C.CString(text))

    s := C.GoString(s1)

    C.free(unsafe.Pointer(s1))

The C string created by C.CString(text) is freed inside the C code of myfunc()

The C code in myfunc() may not be thread safe, but it is called in a single CGO call. Can Go do another C call when one is still running? I thought switching between goroutines didn't happen during execution of C code.

If this is the cause of the crash, a simple mutex will fix it, but this is such a rare thing that I can't test it.

[James Bardin]

On Thursday, May 26, 2016 at 10:34:31 AM UTC-4, Peter Kleiweg wrote:

The C code in myfunc() may not be thread safe, but it is called in a single CGO call. Can Go do another C call when one is still running?

Yes

 

I thought switching between goroutines didn't happen during execution of C code.

Each cgo call blocks a thread, but the runtime will just spawn more threads as needed. For example, the cgo DNS resolver works without blocking the entire program. 

[Dave Cheney]

What was the signal that was received? It should be printed between the panic message and the start of the stack trace.

[Peter Kleiweg]

Op vrijdag 27 mei 2016 01:41:04 UTC+2 schreef Dave Cheney:

> What was the signal that was received? It should be printed between the panic message and the start of the stack trace.

I got this:

fatal error: unexpected signal during runtime execution

[signal 0xb code=0x1 addr=0x40 pc=0x7f71fc5d819c]

[Dave Cheney]

The code at 0x7f71fc5d819c dereferenced an address 0x40 bytes from a null pointer. That PC, if it's correct, is well above where the Go code lives, so it's either corrupt or in your C code. You can use pmaps or ldd to try to figure out what code is living there. Gdb might also be able to disassemble that address.