Bug 1052579 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commentor’s name and original timestamp.

This is the patch I've been using for finding places where string memory is allocated from outside the new string heap.

Any time the JSString class receives a new value for its char buffers, I added a check that the buffer is located in the new StringBufferArena. If not, it will print its PID and infinite-loop so I can attach the VS Debugger and inspect the call stack.

It also checks reallocs, since there were a couple instances where code was trying to "cross arenas" during a realloc. Same behavior - Prints the PID and freezes.
This is the patch I've been using for finding places where string memory is allocated from outside the new string heap.

Any time the JSString class receives a new value for its char buffers, I added a check that the buffer is located in the new StringBufferArena. If not, it will print its PID and infinite-loop so I can attach the VS Debugger and inspect the call stack.

It also checks reallocs, since there were a couple instances where code was trying to "cross arenas" during a realloc. Same behavior - Prints the PID and freezes.

This patch is not intended to be checked in as-is, although something like it may appear in the final product as a `MOZ_ASSERT()` to ensure that nobody accidently adds new code that allocates string buffers in the default heap.

Back to Bug 1052579 Comment 2