chrisb at adobe.com
Tue Jul 29 16:05:45 PDT 2008
I have been spending some time tracking down bug 16800. Bug 16800 got
me looking at how BracketAccessorNode::emitCode works. Links to the
relevant code are provided below:
In the test case for bug 16800, the local variable property is assigned to a
RegisterID* returned from CodeGenerator::newTemporary. The local variable
roperty is pointing to a RegisterID that is the first RegisterID in the last
segment of the SegmentedVector containing all the RegisterID's for
temporaries. The ref count of the RegisterID is zero because it has not
been stuffed into a RefPtr or otherwise had its ref count increased, it is
returned straight through from where it was created.
When BracketAccessorNode::emitCode calls generator.finalDestination(dst),
finalDestination ends up calling CodeGenerator::newTemporary.
CodeGenerator::newTempory "reclaims free register IDs", which it defines as
RegisterID's whose ref count is 0. The RegisterID pointed at by property
meets the criteria of being a free register and newTemporary thus removes it
from the SegmentedVector array. Since the RegisterID was the first
RegisterID in the last segment of the SegmentedVector, property then points
to free'd memory. After freeing the free RegisterID's, newTemporary then
adds a new RegisterID to the end of the SegmentedVector. Most of the time,
the allocations done by the SegmentedVector just restore the memory that was
freed when we were reclaiming the free RegisterID's and then property is
pointing at valid memory again and is in fact pointing at the same
RegisterID that will be returned from this call to newTemporary. When
running with MallocDebug enabled however, different memory ends up being
used for the last segment of the SegmentedVector and property ends up still
pointing at freed memory when we pass it into CodeGenerator::emitGetByVal.
Is there a bug here or am I just not understanding how this code works?
More information about the webkit-dev