This is a code inspection bug. QA: To verify that this bug is fixed, make sure that all callers in of PL_DHashTableInit in the indicated class/file check and handle a failure return result. To verify that this bug is invalid, simply verify (e.g. with lxr) that PL_DHashTableInit is no longer used by the indicated class/file. PL_DHashTableInit returns a PRBool indicating whether it succeeded. PL_DHashTableInit *can* fail. Code can not assume that table->ops or table- >data will be null (in fact it probably will not be), although in all likelyhood table->entryStore will be null it probably isn't safe to assume this. Code at time of bug filing: 876 if (! mNamedDataSources) 877 return NS_ERROR_OUT_OF_MEMORY; 878 879 PL_DHashTableInit(&mResources, &gResourceTableOps, nsnull, 880 sizeof(ResourceHashEntry), PL_DHASH_MIN_SIZE); 881 882 PL_DHashTableInit(&mLiterals, &gLiteralTableOps, nsnull, 883 sizeof(LiteralHashEntry), PL_DHASH_MIN_SIZE); 884 885 PL_DHashTableInit(&mInts, &gIntTableOps, nsnull, 886 sizeof(IntHashEntry), PL_DHASH_MIN_SIZE); 887 888 PL_DHashTableInit(&mDates, &gDateTableOps, nsnull, 889 sizeof(DateHashEntry), PL_DHASH_MIN_SIZE); 890 891 PL_DHashTableInit(&mBlobs, &gBlobTableOps, nsnull, 892 sizeof(BlobHashEntry), PL_DHASH_MIN_SIZE);

Comment on attachment 126832 [details] [diff] [review] proposed changes I guess this is fine, but maybe an assertion would be in order? not sure. (of course, maybe we just need the component manager to assert when a component fails to be created due to certain more fatal errors like NS_ERROR_OUT_OF_MEMORY) r=alecf

checked in