search

libgit2 / git2go

Git to Go; bindings for libgit2. Like McDonald's but tastier.
MIT License
1.93k stars 316 forks source link

`fatal error: unexpected signal during runtime execution` in `Clone(...)` #928

Open patrickdevivo opened 2 years ago

patrickdevivo commented 2 years ago

Hi there! We're seeing a pretty consistent crash in our code that appears to be originating in the Clone call in libgit2 (via git2go). We're using github.com/libgit2/git2go/v33 v33.0.9 and are seeing the following:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf8de5c]

runtime stack:
runtime.throw({0x133c30a?, 0xeddcf4?})
 /usr/local/go/src/runtime/panic.go:992 +0x71
runtime.sigpanic()
 /usr/local/go/src/runtime/signal_unix.go:802 +0x389

goroutine 15 [syscall, locked to thread]:
runtime.cgocall(0xec7c20, 0xc001027960)
 /usr/local/go/src/runtime/cgocall.go:157 +0x5c fp=0xc001027938 sp=0xc001027900 pc=0x4348bc
github.com/libgit2/git2go/v33._Cfunc_git_clone(0xc001856e78, 0x7fe8fc0042d0, 0x7fe8fc004300, 0xc000fbc340)
 _cgo_gotypes.go:3233 +0x4c fp=0xc001027960 sp=0xc001027938 pc=0xaae34c
github.com/libgit2/git2go/v33.Clone.func3(0xc000fbc340?, 0xc001124360?, 0xc001728280?, 0xc001027a50?)
 /go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/clone.go:43 +0x91 fp=0xc0010279b8 sp=0xc001027960 pc=0xac6d91
github.com/libgit2/git2go/v33.Clone({0xc0014043f0?, 0x0?}, {0xc001cb2fc0, 0x1e}, 0xc001124360)
 /go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/clone.go:43 +0x19e fp=0xc001027a60 sp=0xc0010279b8 pc=0xac6ade
...

This is where we're calling out to the Clone in our code: https://github.com/mergestat/fuse/blob/b1165024f3dc65fd498bad3b1f1c8e3b54f73f8e/internal/syncer/git_files.go#L81

We would really appreciate any points anyone may have here - we're trying to understand where the issue is and if it's in our use of the library or elsewhere.

Thanks!

pjbgf commented 2 years ago

@patrickdevivo are you getting this every time you execute or only during long executions? We have experienced a similar issue, which transformed into a new error when we started doing a remote-ls before the clone operation.

For us they tend to happen only after a few hours of executing clone operations, but we are still investigating the root causes.