100% CPU usage on macOS on sleep

AI Investigation:

⏺ Based on my investigation using sequential thinking, I've identified the root cause of the 100% CPU bug in gvproxy on macOS.

Root Cause

The bug is in the replyLoop method in pkg/services/forwarder/udp_proxy.go, specifically in the ECONNREFUSED error handling (lines 83-89).

The Problem

When macOS wakes from sleep, network state changes cause UDP connections to fail. The code has special handling for ECONNREFUSED errors:

  if err, ok := err.(*net.OpError); ok && err.Err == syscall.ECONNREFUSED {
      // retry indefinitely
      goto again
  }

This creates an infinite tight loop when:

1. Mac wakes from sleep with changed network state (proxy/VPN changes)
2. VM sends NTP packets to time servers
3. gvproxy creates UDP connections that fail due to network changes
4. ICMP "port unreachable" messages get queued in the kernel for these sockets
5. proxyConn.Read() immediately returns ECONNREFUSED (doesn't block)
6. Code jumps to again and retries immediately
7. ICMP error persists, Read() returns ECONNREFUSED again instantly
8. Infinite loop at 100% CPU with no blocking or delays

Why Multiple Threads

Each NTP server connection creates a separate replyLoop goroutine (line 129). Multiple NTP servers = multiple spinning goroutines = multiple CPU cores pegged at 100%.

Evidence Match

✅ Happens after sleep - network state changes cause connection failures ✅ Related to proxies/VPNs - routing changes trigger ICMP errors ✅ Multiple threads spinning - one replyLoop per NTP connection ✅ Thread count = NTP connection count - each replyLoop is independent ✅ Connections never close - replyLoop stuck in infinite loop ✅ NTP port 123 specifically - UDP where ICMP errors are common

The Fix

Add safeguards to prevent infinite retry loops:

  // Option 1: Limit consecutive retries
  retryCount := 0
  maxRetries := 10
  again:
  read, err := proxyConn.Read(readBuf)
  if err != nil {
      if err, ok := err.(*net.OpError); ok && err.Err == syscall.ECONNREFUSED {
          retryCount++
          if retryCount < maxRetries {
              time.Sleep(10 * time.Millisecond) // prevent tight loop
              goto again
          }
      }
      return
  }
  retryCount = 0 // reset on successful read

Or more simply, just remove the goto and let ECONNREFUSED errors terminate the connection like other errors, since the 90-second timeout should be sufficient for transient errors.

AI Investigation:

⏺ Based on my investigation using sequential thinking, I've identified the root cause of the 100% CPU bug in gvproxy on macOS.

Root Cause

The bug is in the replyLoop method in pkg/services/forwarder/udp_proxy.go, specifically in the ECONNREFUSED error handling (lines 83-89).

The Problem

When macOS wakes from sleep, network state changes cause UDP connections to fail. The code has special handling for ECONNREFUSED errors:

  if err, ok := err.(*net.OpError); ok && err.Err == syscall.ECONNREFUSED {
      // retry indefinitely
      goto again
  }

This creates an infinite tight loop when:

1. Mac wakes from sleep with changed network state (proxy/VPN changes)
2. VM sends NTP packets to time servers
3. gvproxy creates UDP connections that fail due to network changes
4. ICMP "port unreachable" messages get queued in the kernel for these sockets
5. proxyConn.Read() immediately returns ECONNREFUSED (doesn't block)
6. Code jumps to again and retries immediately
7. ICMP error persists, Read() returns ECONNREFUSED again instantly
8. Infinite loop at 100% CPU with no blocking or delays

Why Multiple Threads

Each NTP server connection creates a separate replyLoop goroutine (line 129). Multiple NTP servers = multiple spinning goroutines = multiple CPU cores pegged at 100%.

Evidence Match

✅ Happens after sleep - network state changes cause connection failures ✅ Related to proxies/VPNs - routing changes trigger ICMP errors ✅ Multiple threads spinning - one replyLoop per NTP connection ✅ Thread count = NTP connection count - each replyLoop is independent ✅ Connections never close - replyLoop stuck in infinite loop ✅ NTP port 123 specifically - UDP where ICMP errors are common

The Fix

Add safeguards to prevent infinite retry loops:

  // Option 1: Limit consecutive retries
  retryCount := 0
  maxRetries := 10
  again:
  read, err := proxyConn.Read(readBuf)
  if err != nil {
      if err, ok := err.(*net.OpError); ok && err.Err == syscall.ECONNREFUSED {
          retryCount++
          if retryCount < maxRetries {
              time.Sleep(10 * time.Millisecond) // prevent tight loop
              goto again
          }
      }
      return
  }
  retryCount = 0 // reset on successful read

Or more simply, just remove the goto and let ECONNREFUSED errors terminate the connection like other errors, since the 90-second timeout should be sufficient for transient errors.

Mac wakes from sleep with changed network state (proxy/VPN changes)

Is this true on your setup when you reproduce this issue?

Mac wakes from sleep with changed network state (proxy/VPN changes)

Is this true on your setup when you reproduce this issue?

Mac wakes from sleep with changed network state (proxy/VPN changes)

Is this true on your setup when you reproduce this issue?

I’ve tried to reproduce this by disabling wifi, and using a wired connection on my mac. Then I put it to sleep and unplug the wired connection, and wake it up. I’ve seen several logs similar to time="2025-12-03T14:39:13+13:00" level=error msg="Can't proxy a datagram to udp: dial udp 132.248.30.3:123: connect: network is unreachable\n" , but I don’t hit 100% CPU, nor do I see worrying threads in lsof. Looks like there is more to it than just connection refused.

I’m working on a way to get a dump of the state of all the go routines when gvproxy gets to 100% CPU, but you will need a modified gvproxy binary.

I’ve tried to reproduce this by disabling wifi, and using a wired connection on my mac. Then I put it to sleep and unplug the wired connection, and wake it up. I’ve seen several logs similar to time="2025-12-03T14:39:13+13:00" level=error msg="Can't proxy a datagram to udp: dial udp 132.248.30.3:123: connect: network is unreachable\n" , but I don’t hit 100% CPU, nor do I see worrying threads in lsof. Looks like there is more to it than just connection refused.

I’m working on a way to get a dump of the state of all the go routines when gvproxy gets to 100% CPU, but you will need a modified gvproxy binary.

I’ve tried to reproduce this by disabling wifi, and using a wired connection on my mac. Then I put it to sleep and unplug the wired connection, and wake it up. I’ve seen several logs similar to time="2025-12-03T14:39:13+13:00" level=error msg="Can't proxy a datagram to udp: dial udp 132.248.30.3:123: connect: network is unreachable\n" , but I don’t hit 100% CPU, nor do I see worrying threads in lsof. Looks like there is more to it than just connection refused.

I’m working on a way to get a dump of the state of all the go routines when gvproxy gets to 100% CPU, but you will need a modified gvproxy binary.

Mac wakes from sleep with changed network state (proxy/VPN changes)

Is this true on your setup when you reproduce this issue?

I'm not entirely sure. I do use Global Secure Access. It's possible that it disconnects when sleeping and then reconnects after waking up.

Mac wakes from sleep with changed network state (proxy/VPN changes)

Is this true on your setup when you reproduce this issue?

I'm not entirely sure. I do use Global Secure Access. It's possible that it disconnects when sleeping and then reconnects after waking up.

Mac wakes from sleep with changed network state (proxy/VPN changes)

Is this true on your setup when you reproduce this issue?

I'm not entirely sure. I do use Global Secure Access. It's possible that it disconnects when sleeping and then reconnects after waking up.

I hope this was fixed by https://github.com/containers/gvisor-tap-vsock/commit/8e7b605e7d6576155c8645054f1ebc6589535bd9

I hope this was fixed by https://github.com/containers/gvisor-tap-vsock/commit/8e7b605e7d6576155c8645054f1ebc6589535bd9

Hi team,

Do we have any date for having the 8e7b605e as part of a release, as v0.8.9 do not include it.

Do we have any date for having the 8e7b605 as part of a release, as v0.8.9 do not include it.

This was backported to v0.8.9 as https://github.com/containers/gvisor-tap-vsock/commit/828122235c704e5a6016712edece182fcf43af1c Are you still seeing this issue with v0.8.9?

@cfergeau the versions that my homebrew are getting are not getting version v0.8.9 :( .

I have built myself and replaced the binary and it works :)

(I'm used to gerrit way of checking, so the tag contains didn't found the commit as it's not the same commit.