Panic on cgo call of secp256k1

[nepet]

Hi folks,

Does anyone of you here have an idea why we are getting this panic log?

fatal: morestack on g0
SIGTRAP: trace trap
PC=0x466a02 m=4 sigcode=128
signal arrived during cgo execution

goroutine 46 [syscall]:
runtime.cgocall(0x7069f0, 0xc0001d1328)
    /usr/local/src/runtime/cgocall.go:157 +0x5c fp=0xc0001d1300 sp=0xc0001d12c8 pc=0x4078bc
github.com/vulpemventures/go-secp256k1-zkp._Cfunc_secp256k1_context_create(0x301)
    _cgo_gotypes.go:298 +0x4d fp=0xc0001d1328 sp=0xc0001d1300 pc=0x6bd0cd
github.com/vulpemventures/go-secp256k1-zkp.ContextCreate(0x301)
    /root/go/pkg/mod/github.com/vulpemventures/go-secp256k1-zkp@v1.1.5/secp256k1.go:74 +0x37 fp=0xc0001d1350 sp=0xc0001d1328 pc=0x6c1817
github.com/vulpemventures/go-elements/confidential.nonceHash({0xc0005ac900, 0x21, 0x30}, {0xc000490f20, 0x20, 0x20})
    /root/go/pkg/mod/github.com/vulpemventures/go-elements@v0.3.7/confidential/confidential.go:175 +0x7b fp=0xc0001d13d0 sp=0xc0001d1350 pc=0x6c2bdb
github.com/vulpemventures/go-elements/confidential.NonceHash(...)
    /root/go/pkg/mod/github.com/vulpemventures/go-elements@v0.3.7/confidential/confidential.go:16

Cheers, Peter

[tiero]

Hey, @nepet this never happened to us so far.

Any chance you can provide us with a "minimal repro" go file that triggers this panic?

From the stack trace it seems to originate from NonceHash call which is very straightforward, can you double-check your inputs?

[nepet]

Thanks for checking on this @tiero! I will check on the inputs. It seems to be a flaky behavior that we could not reproduce so far.

https://github.com/vulpemventures/go-elements/blob/17f0c89d5c42ffb4788b338f35d75e077e3c336e/confidential/confidential.go#L185-L188

The stack trace seems to originate from the ContextCreate method of secp256k1 which is not related to the inputs of NonceHash, or do I miss something here?

[tiero]

oh, ok seems then related to some memory leak. I just quickly read on your reference issue, please be sure to defer any calls, so cgo will release memory before panic

[wtogami]

https://musl.libc.org/ The crash seems to be reproducible with musl libc ... but we haven't seen it crash with ordinary glibc. Everything you deploy in Alpine Linux is built in this way. Something similar happened again just now. Alpine developer claims their FORTIFY stuff is more strict than glibc so it may be exposing memory use errors.

fatal: morestack on g0
SIGTRAP: trace trap
PC=0x466a02 m=7 sigcode=128
signal arrived during cgo execution

goroutine 13777 [syscall]:
runtime.cgocall(0x706d90, 0xc0004bd9f8)
        /usr/local/src/runtime/cgocall.go:157 +0x5c fp=0xc0004bd9d0 sp=0xc0004bd998 pc=0x4078bc
github.com/vulpemventures/go-secp256k1-zkp._Cfunc_secp256k1_context_create(0x301)
        _cgo_gotypes.go:298 +0x4d fp=0xc0004bd9f8 sp=0xc0004bd9d0 pc=0x6bd42d
github.com/vulpemventures/go-secp256k1-zkp.ContextCreate(0x301)
        /root/go/pkg/mod/github.com/vulpemventures/go-secp256k1-zkp@v1.1.5/secp256k1.go:74 +0x37 fp=0xc0004bda20 sp=0xc0004bd9f8 pc=0x6c1b77
github.com/vulpemventures/go-elements/confidential.nonceHash({0xc0004f2180, 0x21, 0x30}, {0xc00046e120, 0x20, 0x20})
        /root/go/pkg/mod/github.com/vulpemventures/go-elements@v0.3.7/confidential/confidential.go:175 +0x7b fp=0xc0004bdaa0 sp=0xc0004bda20 pc=0x6c2f3b
github.com/vulpemventures/go-elements/confidential.NonceHash(...)
        /root/go/pkg/mod/github.com/vulpemventures/go-elements@v0.3.7/confidential/confidential.go:16
github.com/vulpemventures/go-elements/confidential.UnblindOutputWithKey(0xc0005a6240, {0xc00046e120?, 0x3?, 0xc000352080?})
        /root/go/pkg/mod/github.com/vulpemventures/go-elements@v0.3.7/confidential/confidential.go:39 +0x6a fp=0xc0004bdb40 sp=0xc0004bdaa0 pc=0x6c2dea

[wtogami]

https://honnef.co/posts/2015/06/statically_compiled_go_programs__always__even_with_cgo__using_musl/

[wtogami]

happened again ... same place ...

[tiero]

I think the best way would be to have a single go file, with the code stripped down to what caused these crashes, and will then start investigating from there if it's something related to our implementation and/or usage of cgo calls or if it's a golang cgo specific thing.

Eventually then using a Dockerfile we can test on Alpine too.

Thanks

[wtogami]

@nepet since we're reproducing this crash easily on our alpine deployment, could you make a test commit that prints out all the inputs before it calls this so we could try to make a minimal reproducer out of it?

[tiero]

Also paging @altafan in case you have ever experienced this or tried already on alpine/musl.

We never tested outside debian-like evn to be honest