Fix Chrome renderer leak in AIS/ADS-B browser sidecars#60
Merged
Conversation
The MyShipTracking (:8093) and tar1090 (:8090) feeders open a browser context per page load, but openPage() threw on a failed open (blocked site, goto/waitForApi timeout) without closing the context it had just created. Each stalled reload — every ~30s while MyShipTracking blocks the sidecar — orphaned that context's renderer processes on the browser. Measured 496 leaked Chrome renderers (459 AIS + 36 ADS-B) holding tens of GB after ~1h40m, driving the host toward OOM. Close the context on any failed open before rethrowing. For the shared multi-source ADS-B browser the teardown is scoped to the context so sibling tabs survive. Renderer count now stays bounded (~50) under the same blocking condition instead of climbing without limit.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The MyShipTracking (
:8093) and tar1090 (:8090) headless-browser feeders leaked Chrome renderer processes — one browser context per failed page open — until the host ran out of memory.Root cause
openPage()creates a browser context + page, then can throw on a failed open (site blocked,goto/waitForApitimeout). It threw without closing the context it had just created, so that context's renderer processes stayed orphaned on the browser. The AIS feeder reloads every ~30s while MyShipTracking blocks the sidecar, so each stalled cycle leaked ~1-2 renderers.Impact (measured live)
MemAvailabledown to 35 GB and falling, swap 50% used — heading for OOM.Fix
Close the context on any failed open before rethrowing (
tools/ais-myshiptracking-feeder/index.js,tools/adsb-globe-feeder/index.js). For the shared multi-source ADS-B browser the teardown is scoped to the context so sibling source tabs survive.Verification
After reclaiming the leaked processes and restarting the backend with the patched feeders:
MemAvailable35 GB → 86 GB (peaked 104 GB right after reclaim).:8093still serving 0 while it retries) that previously drove it to 496.