Static Analyzer - tracking values through indirection?

Clang Frontend
1

Hi,

I need to write a checker to make sure that the state of the transaction is checked after commit. This is working fine is basic cases, but it seems to fail when I introduce any level of indirection. For example, consider the following:

class TransactionPtr
{
public:
TransactionPtr(DummyTransaction& tr) : m_tr(tr) {}

DummyTransaction* getTransaction() { return &m_tr; }

private:
DummyTransaction& m_tr;
};

int main(int argc, char* argv)
{
DummyTransaction tr;
TransactionPtr trp(tr);

trp.getTransaction()->commit();

if(tr.isSuccessful()) return 0;
else return 1;
}

Running my checker on this reveals that the analyzer has no idea of the connection between trp.m_tr and tr, and so it fails to detect an issue with the above code.

I also tried checkBind(), but it is not called in relation to the TransactionPtr trp(tr); line.

Is this a known limitation, or am I missing something here? I also tried getBaseRegion(), getSuperRegion(), which didn’t lead anywhere. getMemorySpace() on the other hand points to UnknownSpaceRegion.

Thanks!

Gabor

2

Hi,

Never mind this e-mail, I realized that tracking this would involve inter-procedural analysis, which the Static Analyzer currently does not support.

Sorry for the spam!

Gabor

3

I think you mean cross-translation-unit analysis. IPA within one translation unit has been supported for a while. Just to be sure, does your example work if you put definitions of DummyTransaction’s methods in the same translation unit?

Jordan

4

Hi Jordan,

They are in the same TU, in fact, inside the very same file. I’ll be able to give you further details (e.g. the dump()-ed SVals) on Monday.

Can it be that support for same-TU inter-procedural analysis was added after 3.2? We’re using clang 3.2 to avoid stability and backward-compatibility issues.

Thanks!

Gabor

5

Ah, yes. Function and method inlining should already be enabled in 3.2, but constructor (and destructor) inlining was not. Hopefully 3.3 will make your life a bit easier!

Jordan

6

By function and method inlining, you mean, inter-procedural analysis support via inlining the called methods? That seems like an interesting choice. We were just discussing this today, that is, how to efficiently support inter-procedural analysis, and this was one idea that came up. Good to know that we had a right idea then. :slight_smile:

Thanks for the info!

7

That’s our current strategy—in cases where we don’t have a simpler model (such as, say, trivial copy constructors), we simply do an AST-based inline of the called function. There are certainly downsides to this—it’s not very scalable, it doesn’t work across translation units, and it has a fair bit of overhead—but it’s definitely caught more and more bugs over the last year.

We’re interested in expanding our IPA support further, but it’s a large and difficult problem (as I’m sure you discussed), and it’s not where we’re choosing to put our efforts right now. Still, function-level inlining with a translation unit is much, much better than nothing. :slight_smile:

Jordan