Right now if you pass a negative index to nsVoidArray::ReplaceElementAt() it will most likely allocate (unsigned int)<negative index> bytes (i.e. usually close to MAXINT bytes). I would bet anyone calling this function with a negative index has a bug on their side. I discovered this when the DOM treewalker code bugged and ate all the memory in my system. The culprit was this void array mallocing huge chunks of memory. The fix would probably just be these few lines added to the beginning of the method, the warning there to catch bad callers: NS_WARN_IF_FALSE(aIndex >= 0, "nsVoidArray::ReplaceElementAt() called with negative index"); if (aIndex < 0) return PR_FALSE;
jesup was talking about this at some point...
someone attach a patch, and lets get it reviewed and checked in.
This is solved in the patch for 96108 which now has r= and sr=, and will be checked in as soon as I verify I've correctly merged the patch forward. *** This bug has been marked as a duplicate of 96108 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.