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/link: exporting free
c function from c-shared library hangs executable with that library LD_PRELOADed
#26184
Comments
free
c function from shared library hungs executable with that library LD_PRELOADed free
c function from shared library hungs executable with that library LD_PRELOADed
free
c function from shared library hungs executable with that library LD_PRELOADed free
c function from c-shared library hangs executable with that library LD_PRELOADed
I'm also hitting this issue with go1.11.2 on darwin/arm64 by using a gomobile created c-shared library. The issue seems to be that the process is deadlocked here in the while-loop: go/src/runtime/cgo/gcc_libinit.c Lines 34 to 64 in 5929ead
Setting runtime_init_done to 1 is not possible, because it is guarded by the same mutex here: go/src/runtime/cgo/gcc_libinit.c Lines 65 to 71 in 5929ead
@ianlancetaylor is there any risk in moving the lock from line 38 to line 42? |
Your analysis is incorrect: |
You are absolutely right, sorry for the confusion.
I have an reproduceable deadlock in this while-loop in a gomobile iOS
library on first usage of the library but cannot share any code from this.
Let's see if I can create a mininal example causing the same deadlock.
…On Mon, Nov 19, 2018, 22:50 Ian Lance Taylor ***@***.*** wrote:
Your analysis is incorrect: pthread_cond_wait unlocks the mutex, so the
loop does not block x_cgo_notify_runtime_init_done. Something else is
happening.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#26184 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADEcOKIlCiwZdZ4ligNhO_7ybenhGVH_ks5uwyelgaJpZM4U_nyD>
.
|
When a Go c-shared library exports a symbol, all calls to that symbol are delayed until the c-shared library is initialized. The c-shared library initialization code starts a thread that initializes the Go runtime; calls to exported symbols are blocked until that initialization is successful. In this case the c-shared library is exporting a symbol named I can only think of one way to resolve this deadlock. If an exported Go function is called before the Go runtime is initialized, it could check whether the initialization thread has been started. If it hasn't been, then it could start the thread itself. But I don't know how safe that is. After all, the C library itself has not yet completed initialization; is it safe to call I suspect that there is no safe way to implement this. |
#59) # Description Using the C++ SDK in its current state results in programs hanging up while loading the SDK library. The hangup is caused by the `defaultOptions` static, invoking the `Options` default constructor which, in turn, uses CGo. Since that variable is static, it is initialized during the library load, before CGo has a chance to finish initializing its threads and mutexes. This results in a deadlock (see this related issue: golang/go#26184 ) This PR fixes that issue by removing the need of a static "default options" variable. To do so, we need the Options `c_opts` method, which converts the C++ Options class into its equivalent `options` C struct, to be constant. This allows the use of delegating constructors without the need of a pre-allocated default Options instance.
What version of Go are you using (
go version
)?go version go1.10.2 linux/amd64
Does this issue reproduce with the latest release?
No idea
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOCACHE="/home/tumdum/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/tumdum/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build872026307=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I've tried to intercept C function
free
via LD_PRELOAD.This works fine with equivalent C version:
It looks like some sort of deadlock in _cgo_wait_runtime_init_done
What did you expect to see?
Stream of 'y'.
What did you see instead?
Nothing.
The text was updated successfully, but these errors were encountered: