mirror of
https://github.com/stablyai/orca.git
synced 2026-09-22 00:02:31 +00:00
Neil
91a500712c
* fix(crash-reporting): see the renderer memory the heap counters never report Windows renderer crash 36048e26 arrived with 618MB of private renderer memory and a `renderer_memory` breadcrumb reporting a 150MB V8 heap. Both numbers were right: xterm scrollback lives in `Uint32Array` backing stores and glyph atlases live in GPU transfer buffers, and neither is counted by `usedHeapSize`, `mallocedMemory`, or Blink's allocator. That made the report unanalyzable. `renderer_memory_highwater` is the crumb carrying the subsystem census that names what grew, and it is armed on `usedHeapSize / heapSizeLimit`. At 150MB of a 4192MB limit that ratio is 3.6% — nowhere near the 60% mark — so the census never reached a single one of these reports. Measured on Windows (6 worktrees x 4 terminal tabs, 8000 lines each, this app at 4218d505): filling 24 mounted panes moved the renderer working set from 210MB to 656MB while `usedJSHeapSize` stayed at 43MB for the whole run. Sample the renderer's own OS footprint through `process.getProcessMemoryInfo()` (available in the sandboxed preload) and: - report `privateMB`, `residentMB`, and `outsideHeapMB` — the footprint minus everything V8 and Blink admit to holding — on every `renderer_memory` crumb; - arm the highwater census on private-footprint marks (600MB / 1000MB) as well as the heap ratio, so growth outside the JS heap now carries the pane and store census that names it. The footprint read is async, so a sample annotates with the previous read and refreshes in the background: one interval of staleness is irrelevant to a footprint trend, and awaiting it would make every sample reentrant. A shell without the bridge, or a runtime that withholds the read, keeps sampling exactly as before. Retained-breadcrumb keys now distinguish the two threshold ladders; keying only on `thresholdPct` collapsed every footprint crumb onto one slot. crash-diagnostics.ts split at the max-lines budget: memory sampling moves to renderer-memory-sampling.ts and the shared payload shaping to crash-breadcrumb-data.ts. * fix(crash-reporting): retain all renderer memory marks
31 lines
1022 B
TypeScript
31 lines
1022 B
TypeScript
import type { RendererProcessMemory } from '../shared/renderer-process-memory'
|
|
|
|
type ProcessMemorySource = Pick<NodeJS.Process, 'getProcessMemoryInfo'>
|
|
|
|
/**
|
|
* Reads this renderer's OS-level footprint. Available in a sandboxed,
|
|
* context-isolated preload; resolves null when the runtime withholds it so a
|
|
* dropped Electron API can never break renderer diagnostics.
|
|
*/
|
|
export async function readRendererProcessMemory(
|
|
source: ProcessMemorySource = process
|
|
): Promise<RendererProcessMemory | null> {
|
|
try {
|
|
const info = await source.getProcessMemoryInfo()
|
|
if (!isFiniteKilobytes(info?.private)) {
|
|
return null
|
|
}
|
|
return {
|
|
privateKB: info.private,
|
|
// Why optional: Chromium reports no resident set on macOS.
|
|
...(isFiniteKilobytes(info.residentSet) ? { residentKB: info.residentSet } : {})
|
|
}
|
|
} catch {
|
|
return null
|
|
}
|
|
}
|
|
|
|
function isFiniteKilobytes(value: number | undefined): value is number {
|
|
return typeof value === 'number' && Number.isFinite(value) && value >= 0
|
|
}
|