Matthew Hodgson

(of course, having done this, it didn't crash overnight; v8 heap is 700MB in the morning)

good news - it crashed overnight (2022-05-13 02:48:28.7125 +0100). bad news: it still didn't dump core. Perhaps the rlimits got reset on the child process, or perhaps there's something daft...

Testing with a new crash test jig (infinite loop), signed with the same entitlements as used on the renderer process, it dumps core as expected when killed with signal 5:...

Right, off we go: ``` matthew@shadowfax ~ % csrutil status System Integrity Protection status: disabled. % ps axuw | fgrep -i '(renderer)' | grep -i nightly matthew 6517 263.9 1.9...

So i tried with llnode (`brew install llnode`, and then `plugin load /opt/homebrew/opt/llnode/llnode.dylib` on lldb run), but `v8 bt` doesn't give any different info to a normal `bt`, even when...

Just in case I can't attach the v8 debugger successfully (because it's busy tightlooping and OOMing to death), i had a quick look around the stacks of the backtrace above,...

(of course, it didn't crash overnight this time)

Other postmortem v8 debuggers are https://github.com/tjfontaine/lldb-v8 (python 2, doesn't work after porting it to python 3, thanks to `RuntimeError: This resolves the SBAddress using the SBTarget from lldb.target so this...

So, i caught in the act this morning, running under lldb (not using the debug electron i built yesterday). Turns out my poor man's trick of "look for string references...

Hmm. indexeddb.ts has: ``` private reallySave = this.degradable((): Promise => { this.syncTs = Date.now(); // set now to guard against multi-writes ``` ...which is all very well, but i don't...