[haiku-commits] Re: haiku: hrev44966 - in src: kits/support apps/debugger/value/value_nodes
- From: Philippe Houdoin <philippe.houdoin@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 7 Dec 2012 11:22:58 +0100
What happend if the referenceable object was allocated on a stack from
another thread than its destruction one?
On Fri, Dec 7, 2012 at 12:01 AM, <anevilyak@xxxxxxxxx> wrote:
> hrev44966 adds 2 changesets to branch 'master'
> old head: cb44a2a6ef3db2d924be5a56708cbea99ff13e5e
> new head: 0c8935498e54b1698d6e1173d37a5c370a012991
> overview:
> http://cgit.haiku-os.org/haiku/log/?qt=range&q=0c89354+%5Ecb44a2a
>
>
> ----------------------------------------------------------------------------
>
> a34020b: A bit more fine-tuning to BReferenceable debugging.
>
> - Rework quick stack range check as suggested by Ingo.
> - If the ref count is > 1 we invoke the debugger unconditionally.
> - If equal to 1, we first perform a quick heuristic check to see if the
> var might be on the stack. If we can't conclusively determine that is,
> we make certain by comparing to the thread's actual stack range.
>
> 0c89354: Fix one more case of deleting instead of reference releasing.
>
> [ Rene Gollent <anevilyak@xxxxxxxxx>
> ]
>
>
> ----------------------------------------------------------------------------
>
> 2 files changed, 20 insertions(+), 9 deletions(-)
> .../value/value_nodes/BListValueNode.cpp | 6 ++---
> src/kits/support/Referenceable.cpp | 23 +++++++++++++++-----
>
>
> ############################################################################
>
> Commit: a34020ba21777c21f57e3bb765d083b38ae9ad1e
> URL: http://cgit.haiku-os.org/haiku/commit/?id=a34020b
> Author: Rene Gollent <anevilyak@xxxxxxxxx>
> Date: Thu Dec 6 22:57:14 2012 UTC
>
> A bit more fine-tuning to BReferenceable debugging.
>
> - Rework quick stack range check as suggested by Ingo.
> - If the ref count is > 1 we invoke the debugger unconditionally.
> - If equal to 1, we first perform a quick heuristic check to see if the
> var might be on the stack. If we can't conclusively determine that is,
> we make certain by comparing to the thread's actual stack range.
>
>
> ----------------------------------------------------------------------------
>
> diff --git a/src/kits/support/Referenceable.cpp
> b/src/kits/support/Referenceable.cpp
> index 39cc641..1aaedec 100644
> --- a/src/kits/support/Referenceable.cpp
> +++ b/src/kits/support/Referenceable.cpp
> @@ -27,7 +27,8 @@ BReferenceable::BReferenceable()
> BReferenceable::~BReferenceable()
> {
> #ifdef DEBUG
> - if (fReferenceCount != 0) {
> + bool enterDebugger = false;
> + if (fReferenceCount == 1) {
> // 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
> @@ -35,10 +36,22 @@ BReferenceable::~BReferenceable()
> // 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.");
> - }
> + size_t testOffset = (addr_t)this - (addr_t)&test;
> + if (testOffset > 1024 || -testOffset > 1024) {
> + // might still be a stack object, check the
> thread's
> + // stack range to be sure.
> + thread_info info;
> + status_t result =
> get_thread_info(find_thread(NULL), &info);
> + if (result != B_OK || this < info.stack_base
> + || this > info.stack_end) {
> + enterDebugger = true;
> + }
> + }
> + } else if (fReferenceCount != 0)
> + enterDebugger = true;
> +
> + if (enterDebugger)
> + debugger("Deleted referenceable object with non-zero ref
> count.");
> #endif
> }
>
>
>
> ############################################################################
>
> Revision: hrev44966
> Commit: 0c8935498e54b1698d6e1173d37a5c370a012991
> URL: http://cgit.haiku-os.org/haiku/commit/?id=0c89354
> Author: Rene Gollent <anevilyak@xxxxxxxxx>
> Date: Thu Dec 6 22:59:49 2012 UTC
>
> Fix one more case of deleting instead of reference releasing.
>
>
> ----------------------------------------------------------------------------
>
> diff --git a/src/apps/debugger/value/value_nodes/BListValueNode.cpp
> b/src/apps/debugger/value/value_nodes/BListValueNode.cpp
> index 91ea46f..bd0073f 100644
> --- a/src/apps/debugger/value/value_nodes/BListValueNode.cpp
> +++ b/src/apps/debugger/value/value_nodes/BListValueNode.cpp
> @@ -246,29 +246,28 @@
> BListValueNode::ResolvedLocationAndValue(ValueLoader* valueLoader,
> if (strcmp(member->Name(), "fObjectList") == 0) {
> error = baseType->ResolveDataMemberLocation(member,
> *location, memberLocation);
> + BReference<ValueLocation>
> locationRef(memberLocation, true);
> if (error != B_OK) {
> TRACE_LOCALS(
>
> "BListValueNode::ResolvedLocationAndValue(): "
> "failed to resolve location of
> header member: %s\n",
> strerror(error));
> - delete memberLocation;
> return error;
> }
>
> error = valueLoader->LoadValue(memberLocation,
> valueType,
> false, fDataLocation);
> - delete memberLocation;
> if (error != B_OK)
> return error;
> } else if (strcmp(member->Name(), "fItemCount") == 0) {
> error = baseType->ResolveDataMemberLocation(member,
> *location, memberLocation);
> + BReference<ValueLocation>
> locationRef(memberLocation, true);
> if (error != B_OK) {
> TRACE_LOCALS(
>
> "BListValueNode::ResolvedLocationAndValue(): "
> "failed to resolve location of
> header member: %s\n",
> strerror(error));
> - delete memberLocation;
> return error;
> }
>
> @@ -280,7 +279,6 @@ BListValueNode::ResolvedLocationAndValue(ValueLoader*
> valueLoader,
> BVariant listSize;
> error = valueLoader->LoadValue(memberLocation,
> valueType,
> false, listSize);
> - delete memberLocation;
> if (error != B_OK)
> return error;
>
>
>
>
Other related posts:
