-
Notifications
You must be signed in to change notification settings - Fork 68
Open
Labels
bugSomething isn't workingSomething isn't working
Description
While capturing traffic, I occasionally get a segfault:
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x47ce28]
goroutine 21 [running]:
runtime.throw(0xf32349, 0x2a)
/usr/local/go/src/runtime/panic.go:1116 +0x72 fp=0xc0007ff6b8 sp=0xc0007ff688 pc=0x439592
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:726 +0x4ac fp=0xc0007ff6e8 sp=0xc0007ff6b8 pc=0x44fdec
sync.(*poolChain).popTail(0xc00025e010, 0x0, 0x0, 0xc0008c6500)
/usr/local/go/src/sync/poolqueue.go:284 +0x48 fp=0xc0007ff730 sp=0xc0007ff6e8 pc=0x47ce28
sync.(*Pool).getSlow(0x15a75a0, 0x3, 0x0, 0x73c500)
/usr/local/go/src/sync/pool.go:160 +0x97 fp=0xc0007ff788 sp=0xc0007ff730 pc=0x47c157
sync.(*Pool).Get(0x15a75a0, 0x33, 0x33)
/usr/local/go/src/sync/pool.go:137 +0xf6 fp=0xc0007ff7d0 sp=0xc0007ff788 pc=0x47c096
regexp.newBitState(...)
/usr/local/go/src/regexp/backtrack.go:50
regexp.(*Regexp).backtrack(0xc000370d20, 0xc0001c7346, 0x26, 0x122d, 0x0, 0x0, 0x0, 0x0, 0x1b0a480, 0x0, ...)
/usr/local/go/src/regexp/backtrack.go:317 +0x79 fp=0xc0007ff860 sp=0xc0007ff7d0 pc=0x7c3f19
regexp.(*Regexp).doExecute(0xc000370d20, 0x0, 0x0, 0xc0001c7346, 0x26, 0x122d, 0x0, 0x0, 0x0, 0x0, ...)
/usr/local/go/src/regexp/exec.go:535 +0x44d fp=0xc0007ff920 sp=0xc0007ff860 pc=0x7c6a0d
regexp.(*Regexp).doMatch(...)
/usr/local/go/src/regexp/exec.go:514
regexp.(*Regexp).Match(...)
/usr/local/go/src/regexp/regexp.go:531
main.(*HTTPModifier).Rewrite(0xc0007ffd38, 0xc0001c7342, 0x1231, 0x1231, 0x4, 0x4, 0x0)
/go/src/github.com/buger/goreplay/http_modifier.go:76 +0x149d fp=0xc0007ffc90 sp=0xc0007ff920 pc=0xc1f91d
main.CopyMulty(0x7f317886e998, 0xc0003722a0, 0xc00007db20, 0x1, 0x1, 0x0, 0xc0000320f0)
/go/src/github.com/buger/goreplay/emitter.go:108 +0x9d4 fp=0xc0007fff40 sp=0xc0007ffc90 pc=0xc1c8f4
main.(*Emitter).Start.func2(0xc00000fce0, 0xc0000a4820, 0x7f317886e998, 0xc0003722a0)
/go/src/github.com/buger/goreplay/emitter.go:53 +0x8f fp=0xc0007fffc0 sp=0xc0007fff40 pc=0xc39d8f
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc0007fffc8 sp=0xc0007fffc0 pc=0x471c01
created by main.(*Emitter).Start
/go/src/github.com/buger/goreplay/emitter.go:51 +0x119
This ends the current capture AND leaves the capture file in an unusable state (unexpected EOF when you try to unzip it).
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Projects
Milestone
Relationships
Development
Select code repository
Activity
dosubot commentedon Jun 24, 2025
This segfault is likely caused by a rare concurrency issue in Go's regexp engine, which internally uses sync.Pool for temporary allocations. The stack trace and code show that HTTPModifier.Rewrite makes heavy use of regular expressions, and while the code itself doesn't misuse sync.Pool, the Go runtime can hit nil pointer dereferences in sync.Pool under high concurrency or if *regexp.Regexp objects are shared unsafely across goroutines. No direct bug or fix was found in the codebase or documentation, but this pattern matches known Go runtime edge cases with regex and sync.Pool interaction (source).
To reduce the risk, make sure all regexes are pre-compiled and not created dynamically or shared unsafely between goroutines. If possible, try running with Go's race detector enabled, or test with a different Go version to see if the issue persists. Instrumenting the code to log regex creation and usage may help catch unsafe sharing. The capture file becomes unusable because the process crashes mid-write, leaving it incomplete or corrupted.
If you can share a minimal config or steps to reproduce, that would help narrow down the trigger.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

ethanmdavidson commentedon Jun 24, 2025
Here's another segfault stacktrace: