Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/link: exporting `free` c function from c-shared library hangs executable with that library LD_PRELOADed #26184
What version of Go are you using (
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:
Setting runtime_init_done to 1 is not possible, because it is guarded by the same mutex here:
@ianlancetaylor is there any risk in moving the lock from line 38 to line 42?
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.