Memory leak in portmaster-core on Linux (v2.0.0) — Similar to #1870 (closed as resolved) but reproducing on current version.

[ninja-gaijin]

What happened:
Claude helped me write this. I have no idea about this kind of stuff.

Similar symptoms to #1870, which was closed as resolved in October 2025 — but I'm reproducing this reliably on the current release, so filing separately in case it's a regression or a related-but-distinct issue.

portmaster-core RSS grew from a baseline of ~550-600MB to ~20GB over roughly 17 hours of continuous uptime (no reboot). The system eventually became swap-thrashed (13-15GB swap in use, <1GB RAM free), with sustained ~1300% CPU across ~65-84 portmaster-core threads and 80%+ system (kernel) time. The desktop UI was stuck on "connecting to system service" during this period, though the system tray pause control still appeared to function.

Pausing Portmaster via the tray icon caused RSS to drop sharply from ~14GB to ~550-600MB within about 30 seconds. After pausing, RSS stayed flat (550-750MB) over several minutes of continued monitoring, even while heavy local file activity continued in the background (a Windows DJ application running under Wine/Bottles was actively writing metadata tags to ~16,000 audio files on NTFS-mounted drives).

/proc/net/nf_conntrack stayed low (~994-1950 entries) throughout, which seems to rule out connection-tracking-table bloat as the cause — RSS growth did not correlate with tracked connection count. Wine/process thread count was modest (~21 wine-related processes, ~546 total system processes) and didn't appear to correlate with process churn either.

What did you expect to happen?:
portmaster-core memory usage should remain bounded/stable over long uptime periods regardless of local file system activity from monitored applications.

How did you reproduce it?:
Leave Portmaster running for an extended period (12h+, longer than my typical 12-15h/day usage) with sustained local file activity from a process it's actively monitoring — in my case, a Wine/Bottles-hosted Windows application (Serato DJ Pro 3.3.5) doing batch metadata writes to thousands of files on 2x NTFS-mounted drives. Not yet confirmed as a minimal repro (network activity vs. file activity vs. simply long uptime not yet isolated) — will update if I can narrow it further. Note: no unusual network connection volume was involved, this was local file activity, not network traffic, and conntrack count stayed low throughout.

Debug Information:

Portmaster version: 2.0.0-6 (portmaster-bin, AUR — official prebuilt binaries)
OS: CachyOS (Arch-based), kernel 7.1.8-1-cachyos
RAM: 32GB, Swap: 32GB
SPN: not in use

Will forward logs from /var/lib/portmaster/log (couldn't find the folders Core Logs: /opt/safing/portmaster/logs/core / App Logs: /opt/safing/portmaster/logs/app / Notifier Logs: /opt/safing/portmaster/logs/notifier / Start Logs: /opt/safing/portmaster/logs/start per the FAQ) and debug. Let me know who I should send them to. I have sanitised the log files, but can send the originals privately if required.

[github-actions]

Greetings and welcome to our community! As this is the first issue you opened here, we wanted to share some useful infos with you:

• 🗣️ Our community on Discord is super helpful and active. We also have an AI-enabled support bot that knows Portmaster well and can give you immediate help.
• 📖 The Wiki answers all common questions and has many important details. If you can't find an answer there, let us know, so we can add anything that's missing.

[Kizuno18]

Adding retained Linux service history from July 21 through August 20. This is a 96 GiB Nobara 44 workstation, and the Portmaster core self-reports version 2.2.1.

• systemd recorded 17 forced SIGABRTs after Portmaster exceeded its stop timeout, plus 18 main-process exit records.
• The service cgroup repeatedly reported memory peaks between 13.6 GiB and 22.4 GiB. Examples include 19.5 GiB on July 23, 19.3 GiB on July 24, 18.4 GiB on August 4, 18.4 GiB on August 10, 18.3 GiB on August 12, and 22.4 GiB on August 16.
• MemoryPeak is a cgroup metric and may include file cache, so these numbers should not be read as Go heap measurements.

There was also one distinct internal SIGSEGV on August 20. It was an unexpected fault in runtime.selectgo, with the crashing goroutine in netquery.(*Manager).HandleFeed at manager.go:101. A veth/bridge interface had been created about three seconds earlier. The process had run for 13 minutes, the service cgroup peak was 9.7 GiB, and the dump contained 574 goroutine headers, including many packet-handler workers.

I posted the sanitized crash stack and timing on #1870: #1870 (comment)

The host showed unrelated cross-process memory-corruption symptoms shortly afterward, so that single SIGSEGV may have an external contributor. The repeated high cgroup peaks and stop timeouts predate the crash and look independently relevant to this issue.

[ninja-gaijin]

Adding retained Linux service history from July 21 through August 20. This is a 96 GiB Nobara 44 workstation, and the Portmaster core self-reports version 2.2.1.

• systemd recorded 17 forced SIGABRTs after Portmaster exceeded its stop timeout, plus 18 main-process exit records.
• The service cgroup repeatedly reported memory peaks between 13.6 GiB and 22.4 GiB. Examples include 19.5 GiB on July 23, 19.3 GiB on July 24, 18.4 GiB on August 4, 18.4 GiB on August 10, 18.3 GiB on August 12, and 22.4 GiB on August 16.
• MemoryPeak is a cgroup metric and may include file cache, so these numbers should not be read as Go heap measurements.

There was also one distinct internal SIGSEGV on August 20. It was an unexpected fault in runtime.selectgo, with the crashing goroutine in netquery.(*Manager).HandleFeed at manager.go:101. A veth/bridge interface had been created about three seconds earlier. The process had run for 13 minutes, the service cgroup peak was 9.7 GiB, and the dump contained 574 goroutine headers, including many packet-handler workers.

I posted the sanitized crash stack and timing on #1870: #1870 (comment)

The host showed unrelated cross-process memory-corruption symptoms shortly afterward, so that single SIGSEGV may have an external contributor. The repeated high cgroup peaks and stop timeouts predate the crash and look independently relevant to this issue.

Also on Portmaster 2.2.1, different distro (CachyOS) and hardware, seeing the same pattern independently — adding my data point since it lines up closely with what's reported above.

Reproduction:

Confirmed CPU climbing to 74–93% and memory to 24–26GB with LOGLEVEL=warning set (ruling out log-formatting overhead as the cause)
Sequentially closed every process that could plausibly be generating load: a torrent client (fully exited, not paused), a Wine/Bottles application, and its wineserver
CPU and memory did not immediately drop after closing any of these — Portmaster remained pegged at ~75–80% CPU and ~24–26GB memory for several minutes after all three were fully closed, before eventually returning to idle (0% CPU, ~1.2GB memory)
These memory peaks (24–26GB) are in the same order of magnitude as the 13.6–22.4GB cgroup peaks reported above across a completely different distro (Nobara) and hardware — suggesting this is systemic to 2.2.1 rather than environment-specific

Likely contributing factor found in logs:
Grepped a ~50-minute log window (25,443 lines total) during an active spike:

"verdict already set" (from et_handler:886, failed to apply verdict to pkt): 2,990 occurrences — 11.7% of all log lines
Occurs on both inbound/outbound and TCP/UDP traffic
The vast majority reference a single local port tied to my torrent client's forwarded listening port — consistent with a high volume of peer connections generating repeated verdict-retry failures
The retry pattern and associated CPU/memory load persisted for several minutes after the torrent client was fully exited, suggesting connection/verdict state isn't cleaned up promptly once the originating process closes
This may be related to the packet-handler worker goroutines and netquery.HandleFeed internals mentioned above — separate crash signature, but same general subsystem
Separately, also seeing occasional "has no profile" / "failed to get profile for process" errors for at least one process (browser), though far less frequent (3 occurrences in the same window)

Sample (IPs and my listening port redacted):

2026-08-30 23:06:52.980 WRN et_handler:886 filter: failed to apply verdict to pkt IN TCP x.x.x.x: <-> x.x.x.x:17550: verdict already set
2026-08-30 23:06:52.980 WRN et_handler:886 [5x] filter: failed to apply verdict to pkt IN TCP x.x.x.x: <-> x.x.x.x:17550: verdict already set
2026-08-30 23:07:01.930 WRN et_handler:886 filter: failed to apply verdict to pkt IN TCP x.x.x.x: <-> x.x.x.x:12216: verdict already set
2026-08-30 23:07:01.930 WRN et_handler:886 [5x] filter: failed to apply verdict to pkt IN TCP x.x.x.x: <-> x.x.x.x:12216: verdict already set
2026-08-30 23:07:11.891 WRN et_handler:886 [9x] filter: failed to apply verdict to pkt IN TCP x.x.x.x: <-> x.x.x.x:51950: verdict already set

Given the volume of retries relative to total log volume, this looks like a strong candidate for the sustained CPU/memory cost on my end. Happy to provide more of the log or run additional diagnostics if a maintainer wants to look into this further.

For reference: a separate earlier instance of Portmaster on my system crashed after accumulating 10h57m CPU time over 3h27m wall clock and a 20.8GB memory peak, before failing with signal. That instance is not the one described above — this is a second, independently observed occurrence of the same underlying pattern on my end, and now a third independent report overall counting the one above.