Hi, I think in 'ancient' SpiderMonkey, we used to deal with OOM by returning null/false. Other exceptions were reported to the JSContext.
Then we changed this: ReportOutOfMemory now throws the "out of memory" string. This allowed scripts to catch OOMs, for instance when allocating large ArrayBuffers. That made sense, but I think at the time we didn't fully grok the resulting complexity of this change. We have a stream of fuzz bugs that are mostly variations on one of these: * We want to swallow an OOM but forget to call recoverFromOutOfMemory or clearPendingException, so we happily continue with a pending exception set. * We forget to call ReportOutOfMemory, because it's often unclear which functions report OOM and which functions don't. Sometimes within a single function we have code paths that fail and report OOM and other cases that don't report OOM. OOM fuzzing has been quite effective, but it feels like a game of whack-a-mole. It also doesn't help us find and fix similar bugs outside SpiderMonkey. Dealing with OOM everywhere is complicated enough, but I think the exception part makes it even more difficult to get right. Is our only option doubling down on these fuzz bugs and adding more assertions, or can we do better with static analysis, the type system, annotations, something? Thanks, Jan _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
