ooni / netem

84%

main: 84%

LAST BUILD ON BRANCH fix-gvisor-stack-close

branch: fix-gvisor-stack-close

CHANGE BRANCH

x

Reset

Sync Branches

• fix-gvisor-stack-close
• architecture
• chore/upgrade-go1.23
• cleanups
• cov2
• coverage
• debug/dpi
• dnsspoof
• feat/reassemble-refactor
• feat/reassemble-tls
• fix/cname
• fixes
• fixtests
• issue-2464
• issue/1803
• issue/2029
• issue/2461
• issue/2494
• issue/2531
• issue/2556
• issue/2654
• issue/2669e
• main
• moredocs
• moretests
• other_docs
• perf
• quicparse
• racedetect
• updatedeps

Build # 38313030455

Build Type

Pull #52

github

Committed by aagbsn

Commit Message

fix: destroy the GVisor stack on Close

gvisorStack.Close only closed netem's own channel: the GVisor stack's endpoints, protocol
workers and timers kept running, so every closed host leaked about one goroutine per CPU,
plus the stack's buffers, for the life of the process. Tests that create many topologies,
such as probe-cli's netemx QA scenarios run with -race -count=N, accumulated gigabytes.

Close now calls stack.Destroy() after closing the channel. Closing the channel first makes
WriteNotify return at once, so GVisor cannot block on it while the teardown aborts
endpoints. A closed stack also fails new dials at once instead of timing out.

Tested with the new gvisor_test.go (160 goroutines leaked by 5 closed topologies before,
none after), go test -race ./..., and probe-cli's netemx, webconnectivityqa,
webconnectivitylte, telegram, whatsapp and signalclient tests against this tree.

Pull Request Pull Request #52: fix: destroy the GVisor stack on Close

Coverage Stats

7 of 7 new or added lines in 1 file covered. (100.0%)

2 existing lines in 1 file now uncovered.

2523 of 3016 relevant lines covered (83.65%)

0.88 hits per line