runtime: Error related to runtime.open_trampoline in darwin/arm64
#48437
Comments
richard-ramos
changed the title
runtime.open_trampoline in darwing/arm64runtime.open_trampoline in darwin/arm64
dr2chase
added
the
NeedsInvestigation
|
The fault doesn't happen in |
|
Hello, @cherrymui, Thank you! |
|
This looks like |
I use nim which translates to C. How can I identify if something is done with the signal stack? |
|
Seeing similar here: fzwoch/obs-teleport#43 Happening with A little context: OBS Studio is a C library with a C++ UI (Qt). It loads plugins via C interface and plugins can hook back into their system via a C interface too. So the plugin is build with This has been working fine for |
seankhliao
changed the title
runtime.open_trampoline in darwin/arm64runtime.open_trampoline in darwin/arm64
gopherbot
added
the
compiler/runtime
|
Is the c-shared library used by a C/C++ program, or a Go program? Is it the only Go part in that program? Thanks. |
|
The shared library is used by a C/C++ program. And yes, it is the only part in that system that is written in Go. The application can be downloaded here: For the shared library to be loaded it can be placed in this location: With Opon running the application it freezes/hangs. When running from Alternatively that project can be build wiht its |
|
@cherrymui Assigning to you for now since you last replied but please feel free to unassign! |
|
I tried again with most recent code from OBS. This time it crashes at
(well it calls Is there any special memory layout required for Go that the C++/Qt framework may break? Interestingly enough, when I enable the |
|
Looking at it again, I will try to provide a complete repro case: Using the following code: package main
//#include <stdbool.h>
//#include <stdint.h>
import "C"
import (
"unsafe"
)
var obsModulePointer unsafe.Pointer
//export obs_module_set_pointer
func obs_module_set_pointer(module unsafe.Pointer) {
obsModulePointer = module
}
//export obs_current_module
func obs_current_module() unsafe.Pointer {
return obsModulePointer
}
//export obs_module_ver
func obs_module_ver() C.uint32_t {
return 0
}
//export obs_module_load
func obs_module_load() C.bool {
return true
}
func main() {}Compiled with (Go 1.19.3, but also current HEAD): go build -buildmode=c-shared -o obs-testThe result is being wrapped in a small plugin structure: obs-test.plugin
obs-test.plugin/Contents
obs-test.plugin/Contents/MacOS
obs-test.plugin/Contents/MacOS/obs-test
obs-test.plugin/Contents/Info.plistWith <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>obs-test</string>
</dict>
</plist>This plugin structure is then installed at ~/Library/Application\ Support/obs-studio/plugins/obs-teleport.pluginRunning OBS 29.0.0 Beta 2 which is pre-compiled. To allow to attach LLDB to the application I needed to do: codesign -s - -f --entitlements debuggee-entitlement.xml /Applications/OBS.appwith <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.get-task-allow</key>
<true/>
</dict>
</plist>Running OBS with the debugger will show the crash on startup. If I have followed the code path correctly the OBS app successfully opens the library and loads the required symbols from it. The next thing what is happening is that it calls the library's lldb /Applications/OBS.app/Contents/MacOS/OBSThe crash trace: Callstack of all threads at this point: I tried to reduce the number of plugins that are being loaded without significant difference. I checked the code for its own use of I there anything else I can provide or try to isolate the issue? For me it seems to happen on a level where my expertise is quite weak. Ideally we find a fix, but knowing why it goes wrong and understanding why this may be a technical limitation would help ease my mind. |
|
Doing some
or from the Linux manpage:
|
|
Small heads-up. I figured my issue seems not to be connected to Go. At some point in OBS simply calling |
|
Thanks for the investigation. I think the Go runtime only installs sigaltstack if it is not already installed. So if a sigaltstack is active, Go wouldn't change it. Yeah, it is weird... |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
make statusgo-shared-librarywhich does the following:callPrivateRPC()passing the following JSON:What did you expect to see?
Expected to see the result of https://github.com/status-im/status-go/blob/0c0e02e93af31207fedb04f98ae6161cd4bcb3df/services/ext/api.go#L548-L550
What did you see instead?
Application crashes. When running the app with lldb, the following error is seen:
The text was updated successfully, but these errors were encountered: