|
From: Joris K. <Jor...@ai...> - 2012-01-09 09:24:49
|
Yes I saw those but those didn't do the trick :( or my understanding of
how to use these macros is wropng. Maybe I should have left that code in
the example ...
I tried:
void releaseRef() {
ANNOTATE_HAPPENS_BEFORE(&m_nRefCnt);
int nRefCnt = __sync_add_and_fetch(&m_nRefCnt, -1);
if (nRefCnt == 0) {
ANNOTATE_HAPPENS_AFTER(&m_nRefCnt);
delete this;
}
}
I did get the race condition suppressed in some cases by using
VALGRIND_HG_DISABLE_CHECKING / VALGRIND_HG_ENABLE_CHECKING
The problem there is that I do not know the sizeof() the instantiated
object the smart-pointer refers to. Aka if the interitance hierarchy is
C isa B isa A and I have a smartpointer to B then I do not now that the
actual object isa C. I need to know it isa C because that changes the
location of where the vtable-pointer of A is stored. This is especially
the case when I have multiple inheritance that all share the same base.
I think the problem is not with the refcounting, but with the virtual
inheritance. Or, formulated as question, what is the difference between
the generated code with virtual and non-virtual inheritance, and how
does that explain the race condition?
I made an assembly-dump of both the compilations to see whether those
could support my theory of stuff happening after the releaseRef call. I
have an almost negligible knowledge of assembly, but I think that the
generated assembly does not show any instructions after the call to
releaseRef, but just some more instructions before the call.
At the moment I'm not able to post these, but will do if desired. You
can generated them yourselfs using the -S flag, something like:
g++ -g -DINHERIT="public" -S refcnttst.cc -o refcnttst.s
g++ -g -DINHERIT="virtual public" -S refcnttst.cc -o refcnttst-virt.s
regards,
Joris
CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
|
|
From: Joris K. <Jor...@ai...> - 2012-01-09 17:07:43
|
Ok thanks Bart, Tomorrow I'll give a go at running/building a 3.7+. Regards, Joris -----Original Message----- From: bar...@gm... [mailto:bar...@gm...] On Behalf Of Bart Van Assche Sent: Monday, January 09, 2012 5:02 PM To: Joris Koster Cc: val...@li... Subject: Re: [Valgrind-users] virtual inheritance and race conditions On Mon, Jan 9, 2012 at 2:45 PM, Joris Koster <Jor...@ai...> wrote: > joris@grazer:~/tmp/src$ valgrind --version > valgrind-3.6.1-Debian In the 3.7.0 release notes you can see that the following bug has been fixed: 243935 Helgrind: incorrect handling of ANNOTATE_HAPPENS_BEFORE()/AFTER() Bart. CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. |
|
From: Bart V. A. <bva...@ac...> - 2012-01-09 11:19:47
|
On Mon, Jan 9, 2012 at 10:24 AM, Joris Koster <Jor...@ai...> wrote: > Yes I saw those but those didn't do the trick :( Which Valgrind version are you using ? With the trunk version neither Helgrind nor DRD reports any race conditions with the happens before/after annotations in place. Bart. |
|
From: Joris K. <Jor...@ai...> - 2012-01-09 13:45:53
|
With annotations in place just in the releaseRef like this:
#include <valgrind/helgrind.h>
// ..
// ..
void releaseRef(){
ANNOTATE_HAPPENS_BEFORE(&m_nRefCnt);
int nRefCnt = __sync_add_and_fetch(&m_nRefCnt, -1);
if (nRefCnt == 0) {
ANNOTATE_HAPPENS_AFTER(&m_nRefCnt);
delete this;
}
}
at my console:
joris@grazer:~/tmp/src$ uname -a
Linux grazer 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
joris@grazer:~/tmp/src$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
joris@grazer:~/tmp/src$ valgrind --version
valgrind-3.6.1-Debian
joris@grazer:~/tmp/src$ g++ -g -DINHERIT="virtual public" refcnttst.cc -lpthread
joris@grazer:~/tmp/src$ valgrind --tool=helgrind -q ./a.out
==2703== Thread #1 is the program's root thread
==2703==
==2703== Thread #7 was created
==2703== at 0x543585E: clone (clone.S:77)
==2703== by 0x4E36E7F: do_clone.constprop.3 (createthread.c:75)
==2703== by 0x4E38604: pthread_create@@GLIBC_2.2.5 (createthread.c:256)
==2703== by 0x4C29B23: pthread_create_WRK (hg_intercepts.c:257)
==2703== by 0x4C29CA7: pthread_create@* (hg_intercepts.c:288)
==2703== by 0x400C82: main (refcnttst.cc:72)
==2703==
==2703== Possible data race during write of size 8 at 0x5b8d040 by thread #1
==2703== at 0x400EC1: Derived::~Derived() (refcnttst.cc:34)
==2703== by 0x400F2D: Derived::~Derived() (refcnttst.cc:35)
==2703== by 0x400E9E: Base::releaseRef() (refcnttst.cc:24)
==2703== by 0x400CE0: main (refcnttst.cc:82)
==2703== This conflicts with a previous read of size 8 by thread #7
==2703== at 0x400BB8: Thread(void*) (refcnttst.cc:56)
==2703== by 0x4C29C90: mythread_wrapper (hg_intercepts.c:221)
==2703== by 0x4E37EFB: start_thread (pthread_create.c:304)
==2703== by 0x543589C: clone (clone.S:112)
==2703== Address 0x5b8d040 is 0 bytes inside a block of size 24 alloc'd
==2703== at 0x4C28B75: operator new(unsigned long) (vg_replace_malloc.c:261)
==2703== by 0x400BE9: main (refcnttst.cc:62)
==2703==
Joris
-----Original Message-----
From: bar...@gm... on behalf of Bart Van Assche
Sent: Mon 1/9/2012 12:19 PM
To: Joris Koster
Cc: val...@li...
Subject: Re: [Valgrind-users] virtual inheritance and race conditions
On Mon, Jan 9, 2012 at 10:24 AM, Joris Koster <Jor...@ai...> wrote:
> Yes I saw those but those didn't do the trick :(
Which Valgrind version are you using ? With the trunk version neither
Helgrind nor DRD reports any race conditions with the happens
before/after annotations in place.
Bart.
CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
|
|
From: Bart V. A. <bva...@ac...> - 2012-01-09 16:02:15
|
On Mon, Jan 9, 2012 at 2:45 PM, Joris Koster <Jor...@ai...> wrote: > joris@grazer:~/tmp/src$ valgrind --version > valgrind-3.6.1-Debian In the 3.7.0 release notes you can see that the following bug has been fixed: 243935 Helgrind: incorrect handling of ANNOTATE_HAPPENS_BEFORE()/AFTER() Bart. |