Re: [Valgrind-users] New experimental skin: signal handler checker

[Dan K. <da...@ke...>]

Nicholas Nethercote wrote:
> On Thu, 3 Jul 2003, Dan Kegel wrote:
>>BTW, this tool of yours is pretty cool.  I bet a similar
>>test could be applied at compile time using smatch
>>http://smatch.sourceforge.net/
>>That'd be quite a combination -- catch a bunch of them statically,
>>and then use your dynamic tool to find some the static checker missed...
> 
> 
> Ah, I was aware of the Stanford checking project but not smatch.  That's
> cool.  I had thought that this signal handler checking would be much
> better done statically.  Crocus may be put out of business before it's
> even started!  But that would be fine, a static checker would be better.

We need both!

> You mention using the dynamic tool for the ones the static tool misses,
> have you used smatch and know that static misses are common, or is this
> just a guess?  I imagine that signal handler checking would be pretty
> straightforward to do statically.  And once people know they shouldn't
> call these function from signal handlers, it's not a problem that's hard
> to fix, it's more just a case of knowing about it in the first place.  As
> opposed to eg. memory errors, where a dynamic automated tool is very
> useful for finding obscure bugs.

Consider the case where you're doing QA on an open source
project which is huge and hard to compile, and the developers haven't
seen fit to run the static checker on the whole source base yet.
Or consider a closed-source app.  In both cases, the dynamic
checker will work, and the static one won't (because the source is
hard to get or configure).

- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045