How can I ascertain why Expo caused my OS to OOM?

I’m unable to provide a minimal reproducible example, due to an NDA, so I want to assist in the diagnosis as much as is feasible:

It would also help to ensure that I’ve correctly reported it to them, rather than Google (for Android Studio), or Temurin. I’ve traces, but don’t understand them:

If its a memory leak then watch the system as it runs to see which process is leaking.
Also the logs from oom usually point to a process that is using excessive memory.

memstrack should show you what process (pid) is top of the pile for using (pages) and hanging onto memory (peak). For example:

Pages being tracked: 291892 (1140MB)
┌   PID   |    Pages   |    Peak    |   Process Command Line
│   15400 |      45256 |      82531 | /usr/bin/bwrap --args 72 -- launch-script.sh                                                                                                                                                                                                                │
│   15696 |      44492 |      59774 | /app/zen/zen -contentproc -ipcHandle 0 -signalPipe 1 -initialChannelId {30821fa3-2eba-4ebe-9964-facedff94468} -parentPid 2 -greomni /app/zen/omni.ja -appomni /app/zen/browser/omni.ja -appDir /app/zen/browser 1 forkserver                                │
│   15615 |      42322 |      73458 | /app/zen/zen -contentproc -ipcHandle 0 -signalPipe 1 -initialChannelId {30821fa3-2eba-4ebe-9964-facedff94468} -parentPid 2 -greomni /app/zen/omni.ja -appomni /app/zen/browser/omni.ja -appDir /app/zen/browser 1 forkserver                                │
│   15694 |      33727 |      44003 | /app/zen/zen -contentproc -ipcHandle 0 -signalPipe 1 -initialChannelId {30821fa3-2eba-4ebe-9964-facedff94468} -parentPid 2 -greomni /app/zen/omni.ja -appomni /app/zen/browser/omni.ja -appDir /app/zen/browser 1 forkserver                                │
│   15448 |      16774 |      17261 | /app/zen/zen --name app.zen_browser.zen                                                                                                                                                                                                                     │

Won’t tell you WHY it’s leaking, only that something is.

@barryascott, the problem is that it hasn’t yet been reproducible. Can it be retroactively diagnosed, and/or can I change anything to render it easier to retroactively diagnose in the future?

You can run a script to collect memory stats every few minutes and log to a file.
Then when the system breaks look at the end of the log to see the what happened leading up to the oom.