gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Static analyser results for -base (277 potential bugs)


From: David Chisnall
Subject: Re: Static analyser results for -base (277 potential bugs)
Date: Mon, 13 Sep 2010 10:37:26 +0100

On 13 Sep 2010, at 10:11, Fred Kiefer wrote:

> Am 12.09.2010 01:35, schrieb David Chisnall:
>> I've now set up a jail that will check out the code each night and run the 
>> static analyser.  You can find the results here:
>> 
>> http://gnustep.theravensnest.org/
>> 
>> Currently only the link to the results for -base works - it's in the process 
>> of generating the ones for -gui and -back.
>> 
>> David
> 
> None of the links on that page are working, not even the one for base.

They were working just before you checked, but then I broke it, sorry.  It 
takes about 12 hours to run the analyser on the server, because it uses almost 
1GB of RAM[1] and keeps thrashing, so I might give up on that idea for now.  
Maybe GNA could be persuaded to host it?  For now, I'll run it periodically on 
my laptop and upload the results.

> Looking at some of the results for gui I think the static analyser has
> problems with assignments. It doesn't seem to track the properties of a
> variable after an assignment. There the new variable should be treated
> as an alias to the old one until another assignment happens.

Yes, I've filed a bug report for this.  Alias tracking is not yet implemented, 
so it's a known problem that should be fixed eventually.

I've also opened a bug about the word 'copy' in selectors.  The Cocoa API 
guidelines say any method with copy in its name should return an owned 
reference, but that's clearly nonsense as there are about a dozen methods with 
copy in their name in Cocoa, only four of which return an owned reference (and 
two of the ones that don't were added with 10.6).

If you find other false positives, please file a bug on the LLVM bug tracker.  
They have a section dedicated to the static analyser.

> Even with this annoying bug it is impressive how many real problems this
> analysis did catch. I hope to find time to fix a few more of these later
> today.

If you're feeling brave, you can try running scan-build --experimental-checks 
and see what the not-well-tested checks find.  It also currently does not run 
the missing dealloc check or the idempotent operations check by default.  I'll 
upload some results with those enabled a bit later.

David

[1] Some of the analysis algorithms are O(n^2) in terms of the number of 
branches.  With some of the ancient code in GNUstep where people didn't quite 
understand the concept of multiple functions, this can get very slow...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]