On Tue, Aug 28, 2012, at 01:29 PM, Sebastian Kuzminsky wrote: > On Aug 28, 2012, at 08:35 , John Kasunich wrote: > > > I want to raise a red flag about XP and other test driven development > > methods. They work fine for deterministic situations, but you can't > > use testing to prove the absence of race conditions and other rare > > bugs that can occur when doing realtime programming. It is very > > easy to write code that will work fine until one instance of the > > program happens to interrupt another during that single line of code > > that isn't properly re-entrant. Said interrupt may happen once a > > year, or less, and testing will never find it. > > I agree with this. Test suites are necessary but not sufficient. > Additional quality assurance is needed. > > There are tools that help find race conditions - static analyzers are > getting really good. > > The buildbot is currently running every commit through Clang > (http://buildbot.linuxcnc.org/clang/), it's not the best SA tool but it's > free and open source. > > We also have access to Coverity's "Prevent" tool, which is the best SA > tool I've ever used. Coverity gives free access to Prevent to > open-source groups via their "Scan" project. Prevent can detect many > race conditions.
How well (if at all) do those tools deal with memory that is shared between completely independent processes? HAL uses a shared memory block for both the realtime data (signal values), the pointers to that data (component pins), and the metadata needed to manage it all (pin and signal names, types, etc). The first two types of data are inherently atomic, by design. You can disconnect or reconnect a HAL pin from/to a signal, and when the HAL function runs it will either get the value from the old signal or the new one, not some half-way thing. But the metadata is more complex and is protected by a mutex. In theory you could have any number of instances of halcmd running at the same time, each one madly doing loadrt, loadusr, addf, setp, net, unlinkp, show, and other commands, and the data in memory would always be valid. When the dust settles, the current configuration wouldn't neccessarily be what any of the hal files described, since multiple differnet hal files might have been issuing interleaved commands. But a show command will give you an accurate description of the configuration as it exists at that moment, and I'm pretty darned confident that all the metadata structures would be valid. How can any external tool even know which executables might want to mess with those data structures? halcmd isn't the only one, things like halscope and halmeter at least read the metadata, and any time you load a component and it exports pins, parameters, and functions that involves writing to the metadata. That means any user space program that exports hal objects would need to be tested against all other such programs. Or am I missing something about how these tools work? > Prevent analysis of LinuxCNC has not been automated yet, each run is done > manually (by me) so it doesn't happen very often. The most recent run > was back in February… > > Coverity has been changing and upgrading their Scan infrastructure and it > was often kind of broken during 2011, but it seems like maybe it's > stabilizing now. The last run I did did not find any races (but lots of > other defects). They've since upgraded their version of Prevent in Scan > to 6.0, so I should run it again and see if it sees anything new… > > BTW, anyone who wants access to our Prevent results via the Coverity web > UI should mail me the username you want, the email address you want to > use to register, and your first and last name, and I'll make you an > account. > > > -- > Sebastian Kuzminsky > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers -- John Kasunich [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
