>
>
> 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. :(
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
