Coverity indicates a possible OOB write in |BrowserProcessSubThread::BrowserProcessSubThread| [1]. |DCHECK|s are in place, but in release builds these are bypassed. [1] https://dxr.mozilla.org/mozilla-central/source/ipc/glue/BrowserProcessSubThread.cpp#52

Does Coverity suggest a specific case where the index would be out of range? The only construction of a BrowserProcessSubThread that I can find is https://dxr.mozilla.org/mozilla-central/source/xpcom/build/XPCOMInit.cpp#544 which seems valid.

(In reply to Jed Davis [:jld] from comment #1) > Does Coverity suggest a specific case where the index would be out of range? > The only construction of a BrowserProcessSubThread that I can find is > https://dxr.mozilla.org/mozilla-central/source/xpcom/build/XPCOMInit.cpp#544 > which seems valid. I think it's just playing what-if. A agree, that usage seems fine.

Can we resolve this bug as INVALID? This Coverity warning is legitimate because ID_COUNT is a valid enum value of aId but an OOB index. Coverity doesn't care that we range check aId in an assert. Would this warning go away if we change this DCHECK to MOZ_RELEASE_ASSERT? 4. cond_at_least: Checking aId < mozilla::ipc::BrowserProcessSubThread::ID_COUNT implies that aId and this->mIdentifier are at least 2 on the false branch. DCHECK(aId >= 0 && aId < ID_COUNT);

I looked at all the callers, we never pass a value that's not a constant.