go run error?

[casiphia]

fatal error: unexpected signal during runtime execution fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x7f17cdca447b]

runtime stack: runtime.throw(0x74c3c2, 0x2a) /usr/local/go/src/runtime/panic.go:616 +0x81 runtime.sigpanic() /usr/local/go/src/runtime/signal_unix.go:372 +0x28e

goroutine 506 [syscall]: runtime.cgocall(0x68bad0, 0xc420384e68, 0x4) /usr/local/go/src/runtime/cgocall.go:128 +0x64 fp=0xc420384e38 sp=0xc420384e00 pc=0x40eb44 github.com/sbinet/go-python._Cfunc_PyImport_ImportModule(0x7f17bc0008c0, 0x0) _cgo_gotypes.go:3023 +0x4a fp=0xc420384e68 sp=0xc420384e38 pc=0x4f9dba github.com/sbinet/go-python.PyImport_ImportModule(0x73fc40, 0x4, 0x0)

[sbinet]

Hi

That's not much to go one :) Do you have a small reproducer? (And instructions to reproduce it)

[casiphia]

When using the go routine call to invoke the python package function via go-python api, an error occurs and the normal execution without the go rontine call is OK

[sbinet]

fair enough, but do you have some code for me to run so I can debug this issue? PyImport_ImportModule is there:

• https://godoc.org/github.com/sbinet/go-python#PyImport_ImportModule

• https://github.com/sbinet/go-python/blob/master/utilities.go#L162

  func PyImport_ImportModule(name string) *PyObject {
  c_name := C.CString(name)
  defer C.free(unsafe.Pointer(c_name))
  
  return togo(C.PyImport_ImportModule(c_name))
  }

  so I am having a hard time devising a way this could fail.

although, I see in the traceback that you have quite a number of goroutines running... do you hold the GIL when you try to import that python module? (python isn't thread safe so any number of things might happen...)

[casiphia]

Yes, you are right, I query related information, is the cpython GIL lead to not multi-threaded operation, ask if there is any solution?

http://spikeekips.tumblr.com/post/97743913387/embedding-python-in-golang-part-2

[sbinet]

well, the way CPython is written, you have to know about the GIL and know how to work with it. many people tried to remove it and failed to meet the requirements from the BDFL (Guido at the time, if memory serves). (that's one of the reasons why PyPy and StacklessPython exist)

I guess by now, CPython and the GIL are just a fact of life. it's frustrating from a Go point of view, and perhaps go-python could devise a more high-level API that takes this into account (so newcomers wouldn't be bitten by the GIL and the CPython API), but that's work :)

closing this issue (but feel free to reopen if you feel I haven't addressed your concerns!)