Windows C# hosted libbox: memmod-loaded WinTun crashes (runtime.cgocallback / exitsyscall), file-backed loading is stable
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Domain
- backend, operating-systems
Research direction
No source file or test is named. Reproduce the hosted C# case with inbound tun enabled using LIBBOX_DLL_FORCE_MEMMOD_WINTUN=1, then compare it with LIBBOX_DLL_USE_FILE_WINTUN=1 and the pure Go program; done means the hosted path no longer crashes or the file-backed constraint is documented and enforced.
Written by the indexing model from the issue text.
Description
We observed a reproducible crash only in C# hosted mode (Go c-shared loaded by .NET), when WinTun is loaded from in-memory loader path (memmod).
Environment:
Windows
C# host (WinUI app process + service process model)
libbox built as Go c-shared
inbound tun enabled
Symptoms:
fatal error: exitsyscall: syscall frame is no longer valid
runtime.cgocallback in stack
sometimes process exit code -1073741819
Key comparison:
inbound tun disabled: stable
inbound tun enabled + memmod WinTun: crash
inbound tun enabled + file-backed WinTun (LoadLibraryEx): stable (10/10 runs)
pure Go test program + memmod: stable
Interpretation:
The issue seems specific to multi-runtime hosted boundary (.NET CLR + Go c-shared + native callback threads), not WinTun function itself.
Using Windows standard loader path (file-backed DLL) avoids the crash in hosted mode.
Proposed direction:
Keep file-backed WinTun as default in C# hosted scenarios
Keep memmod path for experimental/debug only
Consider documenting this constraint for hosted runtimes
Repro hints:
Set LIBBOX_DLL_FORCE_MEMMOD_WINTUN=1 -> crash likely in hosted mode
Set LIBBOX_DLL_USE_FILE_WINTUN=1 -> stable in hosted mode
- Dominant language
- Go
- Stars
- 240
- Forks
- 240
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SagerNet/sing-tun
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
gvisor: LinkEndpointFilter.Attach never forwards nil, so GVisor.Close leaks all inbound dispatcher goroutines and fdsPossibly taken @arpitjain099 claimed this 45 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
TUN `mixed` stack: TCP never re-injected into tun0 on Linux kernel 7.1 (UDP works, `gvisor` works)Open
Difficulty 4/5 1-2 days Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 70/100
-
Difficulty 3/5 1-2 days Newbie friendliness 76/100
All issues in SagerNet/sing-tun
Similar issues
-
good first issue help wanted v3
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
oras-project/oras-go#1621 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 4 days
-
Chained slog With calls discard previously bound attributesPossibly taken @yuefdev claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
[scanner] TestAgentNowLineStates hard-fails instead of degrading when node is off PATHPossibly taken @arteeh claimed this today. Openagent/scanner ci help wanted kind/test
Difficulty 1/5 Under an hour Newbie friendliness 90/100
hivecommons/hive#12924 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Gentleman-Programming/engram#1940 ·
Maintainers usually reply within 1 day