Todas las ideas/devtools/Plataforma SaaS que automatice la detección, diagnóstico y generación de configuraciones seguras para la interoperabilidad entre runtimes de lenguajes como Go y C#, incluyendo manejo avanzado de señales y gestión de memoria compartida.

GitHubB2Bdevtools

Plataforma SaaS que automatice la detección, diagnóstico y generación de configuraciones seguras para la interoperabilidad entre runtimes de lenguajes como Go y C#, incluyendo manejo avanzado de señales y gestión de memoria compartida.

Detectado hace 8 horas

6.5/ 10

Puntaje general

Convierte esta senal en ventaja

Te ayudamos a construirla, validarla y llegar primero.

Pasamos de la idea al plan: quien compra, que MVP lanzar, como validarlo y que medir antes de invertir meses.

Contexto extra

Ver mas sobre la idea

Te contamos que significa realmente la oportunidad, que problema existe hoy, como esta idea lo resolveria y los conceptos clave detras de ella.

Desglose del puntaje

Urgencia7.0

Tamano de mercado6.0

Viabilidad7.0

Competencia3.0

Dolor

Errores de segmentación (SIGSEGV) al integrar librerías Go compiladas con c-shared y llamadas desde C# debido a conflictos en la gestión de señales y memoria entre ambos runtimes.

Quien pagaria por esto

Equipos de desarrollo de software que integran componentes en Go y C# en aplicaciones críticas, especialmente en empresas de software que requieren alta estabilidad en sistemas híbridos.

Senal de origen

"We hit an SIGSEV when running building a Go library with c-shared and then calling it from C#."

Publicacion original

runtime: `SIGSEGV` with a c-shared library and called from C#

Publicado: hace 8 horas

Repository: golang/go Author: egonelbre ### Go version go version go1.26.2 linux/amd64 ### Output of `go env` in your module/workspace: ```shell AR='ar' CC='gcc' CGO_CFLAGS='-O2 -g' CGO_CPPFLAGS='' CGO_CXXFLAGS='-O2 -g' CGO_ENABLED='1' CGO_FFLAGS='-O2 -g' CGO_LDFLAGS='-O2 -g' CXX='g++' GCCGO='gccgo' GO111MODULE='' GOAMD64='v1' GOARCH='amd64' GOAUTH='netrc' GOBIN='' GOCACHE='/home/egon/.cache/go-build' GOCACHEPROG='' GODEBUG='' GOENV='/home/egon/.config/go/env' GOEXE='' GOEXPERIMENT='' GOFIPS140='off' GOFLAGS='' GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2252078435=/tmp/go-build -gno-record-gcc-switches' GOHOSTARCH='amd64' GOHOSTOS='linux' GOINSECURE='' GOMOD='/home/egon/Code/gist/dotnet-repro/go.mod' GOMODCACHE='/home/egon/go/pkg/mod' GONOPROXY='' GONOSUMDB='' GOOS='linux' GOPATH='/home/egon/go' GOPRIVATE='' GOPROXY='https://proxy.golang.org,direct' GOROOT='/snap/go/11127' GOSUMDB='sum.golang.org' GOTELEMETRY='local' GOTELEMETRYDIR='/home/egon/.config/go/telemetry' GOTMPDIR='' GOTOOLCHAIN='auto' GOTOOLDIR='/snap/go/11127/pkg/tool/linux_amd64' GOVCS='' GOVERSION='go1.26.2' GOWORK='' PKG_CONFIG='pkg-config' ``` ### What did you do? We hit an SIGSEV when running building a Go library with c-shared and then calling it from C#. The issue seems difficult to trigger under normal workflows, but I've managed to narrow the issue down to a reproducer that heavily triggers C# GC and calls Go library in a busy loop. https://gist.github.com/egonelbre/18432be81e1a4e18887e1590ead6f496 AI analysis seems to point that the issue is that Go installs its own sigaltstack and then C# triggers a signal due to it's own GC, which then arrives at a sigaltstack that has been freed. I'm still trying to find a workaround, but I have not found one yet. Installing a custom larger sigaltstack seems to improve things, but it still seems to crash. ### What did you see happen? The failure looks like ``` [dotnet-repro] mode=signal workers=32 iters=1000000 interval=50µs gc=True pid=4300 timeout: the monitored command dumped core ./run.sh: line 35: 4299 Segmentation fault timeout 60 env LD_LIBRARY_PATH=. DOTNET_CLI_HOME=/tmp "$DOTNET_BIN" exit=139 === SIGSEGV on attempt 1 — reproduced ``` ### What did you expect to see? No SIGSEGV. Alternatively, if there's a workaround, it would be nice to have some documentation on how to correctly set it up.

Ver en github ↗