public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@namesys.com>
To: dan carpenter <error27@email.com>
Cc: linux-kernel@vger.kernel.org, smatch-discuss@lists.sf.net
Subject: Re: smatch update / 2.5.64 / kbugs.org
Date: Fri, 7 Mar 2003 09:53:07 +0300	[thread overview]
Message-ID: <20030307095307.E4600@namesys.com> (raw)
In-Reply-To: <20030307064535.20769.qmail@email.com>

Hello!

On Fri, Mar 07, 2003 at 01:45:35AM -0500, dan carpenter wrote:
> > > The smatch bugs for kernel 2.5.64 are up.  The 
> > > new url for the smatch bug database is http://kbugs.org.  
> > Unfortunatelly the bug database does not work. I mean I cannot connect to it.
> Crap...  sorry about that, I screwed up.

> > This script can produce a lot less false positives with even more custom merge rules.
> > Here's the diff that if run on fs/ext3/super.c from current bk tree, produces
> > only one true bug. (your version from cvs produces one real bug and two false positives)
> > (8 less hits on my default build).
> I have uploaded your modifications to CVS.  I'll use it 
> on the next kernel release.  The unfree.pl was just a few
> modifications to the deference_check.pl so your patch
> will cut down on the false positives with that also.

Actually I think these free() checks can be extended a lot, it can detect memory leaks and so on.

I have preliminary working version here, but it was only barely tested (And not tested on real kernel at all).
I will spend more time on it today and then send it in.
Incidentally this new version should also work on non-kernel code too, I think ;)
I think that tracking only negative/NULL returns is not the best way.
My current approach is to add several more states like "exported" which means that this value was added
to externally visible variable. Then upon reaching return/end of function we can see if all the
allocated stuff was freed or exported. Tricky part seems to correctly merge all these states
from different branches of if steatements.

Also is anybody working on "redundant assignments" stuff as described in Standford guys papers?

Bye,
    Oleg

  reply	other threads:[~2003-03-07  6:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-07  6:45 smatch update / 2.5.64 / kbugs.org dan carpenter
2003-03-07  6:53 ` Oleg Drokin [this message]
2003-03-14  8:25   ` Oleg Drokin
  -- strict thread matches above, loose matches on Subject: below --
2003-03-07  8:32 dan carpenter
2003-03-06  8:15 dan carpenter
2003-03-06  7:37 dan carpenter
2003-03-06  7:42 ` Greg KH
2003-03-06 15:37 ` Oleg Drokin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030307095307.E4600@namesys.com \
    --to=green@namesys.com \
    --cc=error27@email.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smatch-discuss@lists.sf.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox