Electron Releases

Description

The macOS PGO collection harness ran the instrumented build with LLVM_PROFILE_FILE=electron-%c%4m.profraw — continuous mode plus shared merge pools. That combination is unsafe when value profiling is enabled.

In continuous mode the LLVM profile runtime mmaps the profraw file MAP_SHARED over the binary's page-aligned profile sections, including __llvm_prf_data. The Values field of each data record holds a raw heap pointer to that process's value-profiling node list. With shared %m pool files those pointers persist into the pool file, so a freshly spawned process maps the same file, reads another process's heap pointer, and dereferences it in __llvm_profile_instrument_target — an instant SIGSEGV under ASLR.

This is what failed the macOS arm64 collect job in run 26916007600: renderer helpers crashed with EXC_BAD_ACCESS on a per-spawn coin flip, killing the speedometer3-run1 and ipc-contextbridge workloads even after retry. The captured .ips reports show three different pids over eight minutes faulting at the identical unmapped address — a stale pointer persisted in the shared pool file. arm64 is hit hardest because Chromium builds mac arm64 with -mllvm -vp-counters-per-site=6, making value-profile sites densest exactly there.

Fix

Pair %c with %p (one continuous-mode file per process) on Darwin so no pointer ever crosses a process boundary. Linux and Windows keep %4m pools — they don't use continuous mode. (Chrome's own collection in tools/pgo/generate_profile.py avoids the bug by not using %c at all; we keep %c because renderer profile writes otherwise race sandbox lockdown at exit and lose Blink coverage.)

The collection script already globs *.profraw and CI uploads the whole directory with --no-merge, so the higher file count needs no downstream changes.

Notes: none