On Aug 28, 2012, at 15:24 , John Kasunich wrote: > > On Tue, Aug 28, 2012, at 01:29 PM, Sebastian Kuzminsky wrote: >> >> 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 (and Clang) don't operate on executables, they operate on source code. You show the SA tool how your source files are related to each other by running something like this: > cd emc2.git/src > scan-build make The scan-build tool spawns make and watches what source files the compiler opens, and what files they include, what #define macros are defined at compile time, etc. From this it builds a parse tree of the entire source code, just like the compiler does. It walks the tree, starting from all the main() functions, and sees what it can prove about the way the code behaves. Sometimes it can prove there are bugs (and sometimes it makes mistakes, because it doesn't know enough about the code). Here's a simple example from Clang, for folks who haven't seen a static analyzer run: http://buildbot.linuxcnc.org/clang/v2.4_branch-sim/v2.4.7-29-gb6b2c63/report-qFUnBQ.html#LN291 At point 1 the SA tool came to a branch. It was unable to prove anything about the contents of the passed-in 'block' variable, so it tried both possibilities (block->o_name == 0, and block->o_name != 0). The case it's showing us in this defect report is the false branch (block->o_name == 0). So as it continues to pretend to execute this function, i pretends that o_name is NULL. At point 2 the SA tool came to a place where o_name gets passed in to strcmp(), which is invalid. (The SA tool has an internal model of standard library functions like strcmp(), so it knows you're not allowed to pass in NULL in this case.) Now, it may be that there is a invariant that makes it so that any time o_name is NULL, settings->skipping_o is also NULL, so this is not a situation that can be encountered in real life. If so, this is a false positive and we might consider clarifying the code, maybe by adding an assert there. Clang does its analysis on a file-by-file basis, so it can't find the kinds of errors you describe above. Prevent does global analysis of all the code you show it, so it can detect the kinds of bugs you describe. Here's part of the documentation of the MISSING_LOCK checker: > The MISSING_LOCK checker tracks when variables are updated with locks. If a > variable update is found that does not have a lock, but usually does have a > lock, a defect is reported. Here's the full documentation, you might need a Scan account to read it (i'll be happy to make a scan account for any linuxcnc developer who wants it): http://scan5.coverity.com:8080/docs/en/webhelp/content/bk04ch01s04s03.html -- 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
