I'm working on OOM bugs in bug 988953 and descendents. Several of those
are hidden out of paranoia.  Let me know if you'd like a Cc.

Please review the OOM rules:

  - If OOM happens, make sure js_ReportOutOfMemory(cx) is called.

    The only exceptions I know of are:

      - You don't have a cx. In that case, check the callers.
        They probably each need to report OOM.

      - You can silently recover from the OOM; i.e. you don't return
        false/null to your caller. This is rare. An example is when
        you're reallocating an array to shrink it. If that fails,
        perhaps you don't care.

      - You're calling js::CrashAtUnhandlableOOM(reason) instead.

  - If you call anything that reports OOM on a cx, and you want to
    "catch" (i.e. squelch) the OOM, use cx->recoverFromOutOfMemory().
    This should be super rare.

One more note: My impression fixing these bugs (the moderately serious
ones, not the trivial ones) is that they don't happen because error
checking is hard. They tend to happen in code where we've deliberately
chosen not to care about OOM. In such code, dangerous bugs and "safe"
crash-on-OOM code ("if this allocation fails, we will crash writing to
null") look exactly the same.

-j

_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Reply via email to