Re: [Valgrind-developers] helgrind: various false negatives/positves

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

>
>
> I suspect most real-world threaded apps use both locks and HB stuff.

Agree. But still the ratio between locks and HB could vary a lot.
Also the users may have different preferences regarding false-positives vs
false-nagatives and between speed and accuracy.

> > Certainly. Right now it is ~60% slower than MSMHelgrind, but there are
> > still things to improve there.
>
> I would say, first figure out if MSMProp1 is a SM that will work well
> for you, in terms of false positive/negative behaviour.  If yes then
> there are probably many tricks to improve performance.

It's hard. With slower machine more tests fail due to timeouts.
So, without making the machine fast I can't really evaluate it.
This is why I am so much interested in unit tests.

>
>
> > Also with MSMProp1 I see less false positives on my apps.
>
> That sounds good, but I did not exactly understand .. you said above
> that MSMProp1 reports ~30% more races.  So are you saying that the 30%
> more are real races that MSMHelgrind missed?  Can you clarify?

Sorry.
The number of false positives *decreased slightly*, mostly due to correct
handling of cond vars and barriers.
The number of true positives *increased significantly*, mostly due to cases
like test10.
Overall number of reports increased with MSMProp1.
This is more like an observation than a precise statistic. I am trying to
collect real numbers and test cases.

>
>
> > Trying to run OpenOffice and Firefox on my machine leads to this.
> >
> > --1052-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> (SIGSEGV) -
> > exiting
> > --1052-- si_code=1;  Faulting address: 0x0;  sp: 0x478CDF4
> >
> > valgrind: the 'impossible' happened:
> >    Killed by fatal signal
> > ==1052==    at 0x3801979C: vgPlain_strlen (m_libcbase.c:232)
> > ==1052==    by 0x38010941: evh__pre_mem_read_asciiz (hg_main.c:5763)
> > ==1052==    by 0x38037D47: vgPlain_client_syscall (syswrap-main.c:850)
> > ==1052==    by 0x38035899: vgPlain_scheduler (scheduler.c:790)
> > ==1052==    by 0x38048C0D: run_a_thread_NORETURN (syswrap-linux.c:89)
>
> Hmm.  I can't imagine how that happened.  If you send a patch against
> the svn trunk, I can try to reproduce and chase the problem for you.

This is unmodified version from svn trunk. Happens on both 32- and 64-bit.
Looks like a common issue on my system, some other programs (e.g. acroread)
fail as well.
Is there anything I can do to help reproduce it?

>
> konqueror is not very threaded; I think this will not tell you anything
> useful.
>

Yep, I see this already. :(