DNS TLS transport + naive detour causes goroutine leak → iOS OOM

[laurdawn]

Description

On iOS (NetworkExtension, ~50MB memory limit), using a naive proxy as the detour for DNS-over-TLS causes goroutines to leak indefinitely, eventually triggering OOM.

Environment

• sing-box version: 1.14.0-alpha.20
• Go version: go1.25.9, ios/arm64
• iOS NetworkExtension

Configuration (relevant parts)

{
  "dns": {
    "servers": [
      {
        "type": "tls",
        "tag": "google",
        "detour": "auto-out",       // ← DNS queries go through auto-out → naive
        "server": "8.8.8.8"
      }
    ]
  },
  "outbounds": [
    {
      "type": "naive",
      "tag": "...",
      "server": "...",
      "server_port": 443,
      "username": "...",
      "password": "...",
      "tls": { "enabled": true }
    }
  ]
}

Symptoms

• Memory usage grows to ~45MB (iOS limit ~50MB)
• 364 goroutines, of which 262 are stuck in cronet/naive/DNS TLS path
• Process eventually OOM-killed by iOS jetsam

Goroutine profile breakdown

Count	Stuck at	Stage
120	crypto/tls.(*Conn).writeRecordLocked	TLS handshake write blocked
48	crypto/tls.(*Conn).handshakeContext.func2	Timed out, goroutine leaked
11	cronet.(*BidirectionalConn).Write	Post-handshake data write
11	cronet.(*BidirectionalConn).Read	Post-handshake data read
2	crypto/tls.(*Conn).readRecordOrCCS	TLS handshake read blocked

The distribution across 5 different stages proves accumulation over time (not a one-time event). 48 goroutines already exceeded the 15s timeout; 72 are still within the timeout window.

Full call chain for the 120 stuck goroutines:

dns.Router.Exchange
  → dns.Client.exchangeToTransport
    → TLSTransport.Exchange
      → ConnPool.acquireOrdered
        → ConnPool.dial
          → tls.DialTLSContext → clientHandshake
            → writeRecordLocked → BidirectionalConn.Write
              → select { case <-c.write: ... }  ← blocked forever

Root cause

Two bugs combine to cause this:

1. BidirectionalConn does not support deadlines

https://github.com/SagerNet/cronet-go/blob/main/bidirectional_conn.go#L291-L301

func (c *BidirectionalConn) SetDeadline(t time.Time) error      { return os.ErrInvalid }
func (c *BidirectionalConn) SetReadDeadline(t time.Time) error  { return os.ErrInvalid }
func (c *BidirectionalConn) SetWriteDeadline(t time.Time) error { return os.ErrInvalid }

When crypto/tls.HandshakeContext(ctx) tries to set the deadline on the underlying connection, it gets os.ErrInvalid. The TLS handshake proceeds without any write timeout.

BidirectionalConn.Write() calls c.stream.Write() (async, non-blocking CGO) then blocks on a Go channel waiting for the OnWriteCompleted callback from the Cronet engine. If the callback never arrives (server unresponsive, HTTP/2 flow control exhausted, etc.), the goroutine is permanently stuck.

2. ConnPoolOrdered has no concurrent dial limiting

https://github.com/SagerNet/sing-box/blob/main/dns/transport/conn_pool.go#L247-L301

func (p *ConnPool[T]) acquireOrdered(...) {
    for {
        // check idle connections → none found
        conn, err := p.dial(ctx, currentState, dial)  // ← every caller starts a new dial
        // dial blocks forever (bug #1) → never returns → goroutine leaked
    }
}

Unlike ConnPoolSingle mode (which has current.connecting to prevent concurrent dials), ConnPoolOrdered allows every caller to start a new dial concurrently. When each dial blocks forever, every new DNS query leaks a goroutine.

Combined effect

1. DNS query arrives → tries to dial DNS-over-TLS through naive proxy
2. TLS handshake starts → writes to BidirectionalConn → blocks waiting for Cronet callback
3. Callback never arrives (server unresponsive / flow control stalled)
4. 15s timeout → HandshakeContext returns error, but the spawned clientHandshake goroutine is still stuck in Write → goroutine leaked
5. Next DNS query → same thing → more goroutines leaked
6. Repeat 120+ times → OOM

Suggested fixes

1. ConnPoolOrdered should limit concurrent dials, similar to ConnPoolSingle's connecting mechanism
2. BidirectionalConn should support deadlines by using context.AfterFunc to close the connection (send to c.close / c.done) when the deadline expires, since the underlying Cronet stream API doesn't support native deadlines
3. DNS transport dial should have a hard timeout that forcibly closes the underlying connection, not just cancels the context

Profile data

Full memory profile dump available if needed (heap, goroutine, allocs profiles from iOS memory pressure callback).

[laurdawn]

2026-05-03T08-12-40.zip

[laurdawn]

Update: v1.14.0-alpha.21-438772508 still leaks (worse goroutine count)

After upgrading to the latest alpha with DNS timeout + cronet-go fixes, the OOM frequency decreased (once per day vs multiple times), but the goroutine leak is actually worse when it does trigger.

New dump comparison

Metric	Previous (246d6a5)	Latest (4387725)
Goroutines	350	641
Stack memory	5.9 MB	9.3 MB
Available memory	8.9 MB	4.5 MB
DNS-related stuck goroutines	77	~180

New evidence: DNS timeout cleanup chain is broken

The 10s DNS timeout fires correctly (113 propagateCancel.func2 goroutines prove this), but the cleanup fails at step 3:

1. DNS 10s timeout → context cancelled                          ✓ works
2. handshakeContext detects cancel → calls tls.Conn.Close()     ✓ works  
3. tls.Close() → sends close_notify → BidirectionalConn.Write  ✗ STUCK

16 goroutines stuck in closeNotify:

github.com/sagernet/cronet-go.(*BidirectionalConn).Write
  crypto/tls.(*Conn).writeRecordLocked
    crypto/tls.(*Conn).sendAlertLocked
      crypto/tls.(*Conn).closeNotify
        crypto/tls.(*Conn).Close
          github.com/sagernet/sing-box/dns/transport.setConnDeadline.func1

This proves that even after DNS timeout cancels the context, the TLS graceful shutdown itself gets stuck because BidirectionalConn.Write does not respect context cancellation — it only selects on c.write, c.done, and c.close channels.

New leak path: waitReady (52 goroutines)

github.com/sagernet/cronet-go.(*BidirectionalConn).waitReady (inline)
  github.com/sagernet/cronet-go.(*BidirectionalConn).Write
    ...TLS handshake via acquireOrdered...

52 goroutines are stuck waiting for OnStreamReady callback that never arrives. If the underlying Cronet connection fails silently (no callback fired), these goroutines leak permanently.

Stuck goroutine breakdown (641 total)

Location	Count	Notes
waitReady → Write (TLS handshake)	52	New — stream never became ready
Write → TLS handshake writeRecord	17	Same as before
Write → TLS flush	12	Same as before
Write → DNS WriteMessage	10	Post-handshake, writing DNS query
Write → closeNotify	16	New — TLS close stuck
Read → TLS handshake (ServerHello)	25	Waiting for server response
Read → DNS response	48	Post-handshake, waiting for DNS reply
propagateCancel.func2	113	Context cancel watchers
handshakeContext.func2	113	TLS internal goroutines
connectionCopy (normal traffic)	22	Normal
Other (gvisor, udpnat, etc.)	~163	Normal background

Root cause confirmed

BidirectionalConn.Write and BidirectionalConn.Read do not monitor the passed context. The select statement:

select {
case <-c.write:
    return len(p), nil
case <-c.done:
    return 0, c.err
case <-c.close:
    return 0, net.ErrClosed
}

...has no case <-ctx.Done() branch. When DNS timeout fires, the context is cancelled, but Write/Read remain blocked until Cronet fires a callback (which may never happen).

Suggested fix

Add context awareness to BidirectionalConn:

func (e StreamEngine) CreateConn(ctx context.Context, ...) *BidirectionalConn {
    conn := &BidirectionalConn{
        ctx: ctx,  // store context
        ...
    }
}

// In Write's final select:
select {
case <-c.write:
    return len(p), nil
case <-c.done:
    return 0, c.err
case <-c.close:
    return 0, net.ErrClosed
case <-c.ctx.Done():
    c.stream.Cancel()
    return 0, c.ctx.Err()
}

This would allow the DNS timeout to propagate all the way down and cancel the stuck Cronet stream.

[laurdawn]

Fixed in v1.14.0-alpha.22. Verified on iOS — no more OOM restarts after running for a full day.