A static-analysis framework for GCC

jezuch — Fri, 06 Dec 2019 11:59:25 +0000

I'm a sucker for static analysis, so even though I don't use C or C++ anymore, it's a huge YES from me!

A question, though: how many warnings it reports on gcc's code base itself? :)

A static-analysis framework for GCC

roblucid — Thu, 05 Dec 2019 12:04:06 +0000

This is such a generous awesome post to read, I do hope cross-fertilisation of ideas and experience benefits bi-directionally!

A static-analysis framework for GCC

error27 — Thu, 05 Dec 2019 09:16:07 +0000

The malloc test looks like how I used to write Smatch checks ten years ago. It's a mistake. One of the comments raises that question: "// TODO: or should this be a different state machine?" The answer is yes, you want lots of little checks.

There are too many states. You don't need start state, or end state. The state transitions are actually not interesting at all. What you do need is a &merged state. In Smatch merging groups of states is the where all the magic happens.

First create a module to record all the values of all the variables. The malloc() test is tracking conditions to try tell when the pointer is NULL vs non-NULL which makes every check too complicated. The value tracking module will be complicated but it's re-used by everything.

In Smatch there are two automatic states which every check inherits &undefined and &merged. Then most checks will just have one state after that. There would be three separate checks for unchecked malloc, double frees, and memory leaks. If we are dereferencing a variable and the value tracker says it can be NULL and the malloc check says it is &malloced then print a warning about an unchecked malloc. The &freed check is even easier. If we're dereferencing or freeing a variable and it's &freed on any path then complain.

Smatch has a leak checker but it's too conservative so it misses a lot of bugs. I guess in this case you really would want to re-use the allocation and free information but I would still make it a separate check. I would export an is_freed() function from the freed check. Then the approach would be at the end of parsing a function 1) Are we on an error path (use the value tracker for this)? Smatch is pretty kernel centric but you could have a project specific hook for this. 2) If so, iterate through all the allocated pointers. 3) Complain if they are non-NULL and not is_freed().

Smatch is ten years ahead of where GCC is at this point. But you could just copy Smatch in just a year or two because I took so many wrong turns and because I am a slow typist...

LWN: Comments on "A static-analysis framework for GCC"

A static-analysis framework for GCC

A static-analysis framework for GCC

A static-analysis framework for GCC