Closed
Bug 641036
Opened 14 years ago
Closed 14 years ago
Add ASSERT to catch incorrect declaration of GCMember
Categories
(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P2)
Tamarin Graveyard
Garbage Collection (mmGC)
Tracking
(Not tracked)
RESOLVED
FIXED
Q3 11 - Serrano
People
(Reporter: bgetlin, Assigned: treilly)
References
Details
Attachments
(1 file)
8.27 KB,
patch
|
lhansen
:
review+
|
Details | Diff | Splinter Review |
Within the scope of a GC defined object (GCRoot, GCObject, GCFinalizedObject) method it's possible to declare a GCMember on the stack.
void MyGCObject::MyFoo()
{
// This will likely cause crash as it attempts to add a write barrier to the stack
GCMember<GCObject> crash;
}
Solve it with a check on construction of the GCMember to see if the memory address is on the stack:
#ifdef DEBUG
static bool IsAddressOnStack(void *address)
{
uintptr_t stackBase = VMPI_getThreadStackBase();
char stackTop;
return ((uintptr_t)address > (uintptr_t)&stackTop && (uintptr_t)address < stackBase);
}
#endif
Updated•14 years ago
|
Assignee: nobody → treilly
Priority: -- → P3
Hardware: x86 → All
Target Milestone: --- → Q3 11 - Serrano
Updated•14 years ago
|
Priority: P3 → P2
Assignee | ||
Comment 1•14 years ago
|
||
Attachment #526290 -
Flags: review?(lhansen)
Comment 2•14 years ago
|
||
Comment on attachment 526290 [details] [diff] [review]
MErge GCMember-inlines.h and GCMemberBase-inlines and apply assert to all GCMember ctors
Not clear to me why you're checking "&(this->t)" and not simply "this".
Attachment #526290 -
Flags: review?(lhansen) → review+
Assignee | ||
Comment 3•14 years ago
|
||
(In reply to comment #2)
> Not clear to me why you're checking "&(this->t)" and not simply "this".
Me neither.
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•