Hi all,
An update on the abort case bug.
Below is one of the responses I got from the valgrind mailing list about
my inquiry. In short, the helgrind log I received seems not to be
absolutely correct and thus is unfortunately of very limited use for
troubleshooting.
There are new versions out and I will ask Lorenzo if it is possible to
run one of those. I'll do that via private mail as I need to forward
some more messages (unfortunately the valgrind mailing list archive
lacks behind several days, so I can not yet refer to the archive...).
Rainer
> ---------- Forwarded message ----------
> From: Julian Seward < >
> Date: Mon, Sep 22, 2008 at 8:54 PM
> Subject: Re: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: valgrind-users@lists.sourceforge.net
> Cc: Konstantin Serebryany < >, Rainer
> Gerhards < m>
>
>
>
> On Monday 22 September 2008, Konstantin Serebryany wrote:
>
> > helgrind is under active development now in two separate branches
> > (HGDEV & YARD).
> > The version in trunk is outdated. Please try YARD first:
> > svn co svn://svn.valgrind.org/valgrind/branches/YARD YARD
>
> Yes, do try YARD; you might like it more than the 3.3.1 helgrind.
>
> Nevertheless, the error you show:
>
> > > ==31831== Possible data race during read of size 4 at 0x6622E8
> > > ==31831== at 0x50464FE: pthread_mutex_lock
> (pthread_mutex_lock.c:87)
> > > ==31831== by 0x4C2217B: pthread_mutex_lock
(hg_intercepts.c:400)
> > > ==31831== by 0x420AFC: dbgGetThrdInfo (debug.c:604)
> > [...]
>
> should have been suppressed, so you should not see it. It is due to
an
> internal implementation limitation which is hard to avoid, so in some
> cases we suppress errors which we know cannot be from end-user code.
>
> I think the relevant suppression in glibc-2.34567-NPTL-helgrind.supp
> is:
>
> {
> helgrind-glibc25-101
> Helgrind:Race
> obj:/lib*/libpthread-2.5.*so
> fun:pthread_*
> }
>
> (or corresponding other versions for glibc > 2.5, in the same file)
>
> One possible reason it did not suppress the error is that you have
> debug information on/for your libpthread, which is an unusual setup
> that
> Helgrind has not been properly tested against.
>
> But I am not 100% sure about that.
>
> * if you uninstall the libc debuginfo rpm/deb, does that change
> anything?
>
> * what glibc version are you using?
>
> J
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
An update on the abort case bug.
Below is one of the responses I got from the valgrind mailing list about
my inquiry. In short, the helgrind log I received seems not to be
absolutely correct and thus is unfortunately of very limited use for
troubleshooting.
There are new versions out and I will ask Lorenzo if it is possible to
run one of those. I'll do that via private mail as I need to forward
some more messages (unfortunately the valgrind mailing list archive
lacks behind several days, so I can not yet refer to the archive...).
Rainer
> ---------- Forwarded message ----------
> From: Julian Seward < >
> Date: Mon, Sep 22, 2008 at 8:54 PM
> Subject: Re: [Valgrind-users] helgrind points to race in
> pthread_mutex_lock?
> To: valgrind-users@lists.sourceforge.net
> Cc: Konstantin Serebryany < >, Rainer
> Gerhards < m>
>
>
>
> On Monday 22 September 2008, Konstantin Serebryany wrote:
>
> > helgrind is under active development now in two separate branches
> > (HGDEV & YARD).
> > The version in trunk is outdated. Please try YARD first:
> > svn co svn://svn.valgrind.org/valgrind/branches/YARD YARD
>
> Yes, do try YARD; you might like it more than the 3.3.1 helgrind.
>
> Nevertheless, the error you show:
>
> > > ==31831== Possible data race during read of size 4 at 0x6622E8
> > > ==31831== at 0x50464FE: pthread_mutex_lock
> (pthread_mutex_lock.c:87)
> > > ==31831== by 0x4C2217B: pthread_mutex_lock
(hg_intercepts.c:400)
> > > ==31831== by 0x420AFC: dbgGetThrdInfo (debug.c:604)
> > [...]
>
> should have been suppressed, so you should not see it. It is due to
an
> internal implementation limitation which is hard to avoid, so in some
> cases we suppress errors which we know cannot be from end-user code.
>
> I think the relevant suppression in glibc-2.34567-NPTL-helgrind.supp
> is:
>
> {
> helgrind-glibc25-101
> Helgrind:Race
> obj:/lib*/libpthread-2.5.*so
> fun:pthread_*
> }
>
> (or corresponding other versions for glibc > 2.5, in the same file)
>
> One possible reason it did not suppress the error is that you have
> debug information on/for your libpthread, which is an unusual setup
> that
> Helgrind has not been properly tested against.
>
> But I am not 100% sure about that.
>
> * if you uninstall the libc debuginfo rpm/deb, does that change
> anything?
>
> * what glibc version are you using?
>
> J
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog