> > I don't think you can have zero false positives and zero false > > negatives at the same time (holy grail ...), because all these state > > machines are different approximations to something which is NP-complete > > (and therefore which we cannot compute exactly). > > Oh, sure. > I think that it makes sense to have several different machines in helgrind > so that a user can choose one that fits his application best. > For example, if an application never creates/join threads (except for > startup/shutdown) and does not use semahpores, cond vars, message queues, > etc, Eraser will be enough.
Using only locks, no semaphores, cond vars, MQs, no create/join, sounds unlikely to me :-) > If on contrary the application never use locks (but uses barriers, > semaphores, message queues, etc) locksets are useless. > The applications I try to analyze use both locks and HB stuff, so I need > both. I suspect most real-world threaded apps use both locks and HB stuff. > > Is it really needed? I don't know. But I don't know how to prove/argue > > that it is not needed. Alternative question is, is it possible to do > > this cheaply/incrementally? > > I thought about using unique lock id in locksets instead of Lock*. > It leads to a problem of mapping from the id to Lock* though... But we only > need this while reporting a race. Interesting possibility. > Yea... Perhaps we could garbage-collect old segments and if some SVal > still refers to a deleted one, behave conservatively. I think we can import some ideas from the world of garbage collection. Basically scan through shadow memory at a rate proportional to the rate of (simulated) instruction execution (rate may be selected adaptively). * some set S of segments are considered for deletion * once the scan starts, we guarantee to not create any more references to any segment in S * during the scan, if any SVal is seen to refer to an element of S, then that element is removed from S At the end of a scan, therefore, it is safe to delete the remaining segments in S. The scan then starts again. This makes it possible to recover memory from unreferenced segments at some constant cost per simulated instruction. Or something like that. > 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. > I've been trying both machines on some of my applications. MSMProp1 reports > ~30% more races. > Those extra races look similar to test10. Most (but not all!) of them look > harmless which makes me think about classifying data races somehow. > See e.g. http://www.eecs.umich.edu/~nsatish/DataRace-PLDI07.html. Yes. Also the Racetrack paper (Rodehoffer et al) has some useful ideas about classification. > 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? > 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. > I have better luck with konqueror, I'll try to compare the two machines on > it. konqueror is not very threaded; I think this will not tell you anything useful. J ------------------------------------------------------------------------- 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
