Description of problem:
I've been writing an experimental static analysis tool to detect bugs commonly occurring within C Python extension modules:
  https://fedorahosted.org/gcc-python-plugin/
  http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html
  http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts

I ran the latest version of the tool (in git master; post 0.9) on
duplicity-0.6.17-2.fc17.src.rpm, and it reports various errors.

You can see a list of errors here, triaged into categories (from most significant to least significant):
http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2012-03-03/duplicity-0.6.17-2.fc17/

I've manually reviewed the issues reported by the tool.

Within the category "Reference leaks" the 1 issue reported appears to be a genuine leak for the error-handling case where the result from rs_job_iter(sig_loader, &buf) != RS_DONE: the _librsync_DeltaMakerObject object allocated will not be released for the lifetime of the process; there needs to be a:
    Py_DECREF(dm);
before the
    return NULL;

Within the category "Reference leak within initialization" the 1 issue reported appears to be inconsequential (this code is called once on module import).

Within the category "Segfaults within error-handling paths" the 3 issues reported could only happen under very low memory-conditions when the module is first imported.

Within the category "Returning (PyObject*)NULL without setting an exception" the 4 issues reported appear to be false positives: the checker doesn't know that  _librsync_seterror() presumably sets the exception state for the current thread.

There may of course be other bugs in my checker tool.

Hope this is helpful; let me know if you need help reading the logs that the tool generates - I know that it could use some improvement.

Version-Release number of selected component (if applicable):
duplicity-0.6.17-2.fc17
gcc-python-plugin post-0.9 git 57a93b9426e8bfdb2787d1f6ee3941e1e475abab running the checker in an *f16* chroot