[haiku-commits] Re: haiku: hrev44964 - in src: kits/support apps/debugger/controllers apps/debugger/dwarf
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 06 Dec 2012 14:46:27 +0100
On 12/06/2012 02:10 AM, anevilyak@xxxxxxxxx wrote:
diff --git a/src/kits/support/Referenceable.cpp
b/src/kits/support/Referenceable.cpp
index 6b2ee36..39cc641 100644
--- a/src/kits/support/Referenceable.cpp
+++ b/src/kits/support/Referenceable.cpp
@@ -27,8 +27,18 @@ BReferenceable::BReferenceable()
BReferenceable::~BReferenceable()
{
#ifdef DEBUG
- if (fReferenceCount > 1)
- debugger("Deleted object which still had references.\n");
+ if (fReferenceCount != 0) {
+ // Simple heuristic to test if this object was allocated
+ // on the stack: check if this is within 1KB in either
+ // direction of the current stack address, and the reference
+ // count is 1. If so, we don't flag a warning since that would
+ // imply the object was allocated/destroyed on the stack
+ // without any references being acquired or released.
+ char test;
+ int64 testOffset = (int64)this - (int64)&test;
+ if (testOffset < -1024 || testOffset > 1024 || fReferenceCount
!= 1)
+ debugger("Deleted referenceable object with non-zero ref
count.");
+ }
#endif
}
Fetch the thread info and check against the thread's stack, when the
heuristic fails? It will probably mostly work, but I can imagine that it
might not, if one also allocates a largish buffer on the stack (e.g.
char[B_PATH_NAME_LENGTH]).
BTW, you can use size_t instead of messing around with int64. Not sure,
if it adds to the readability, but at least theoretically int64 could
overflow on 64-bit architectures.
size_t testOffset = (addr_t)this - (addr_t)&test;
if (testOffset > 1024 && -testOffset > 1024)
...
CU, Ingo
Other related posts:
