From Fedora Project Wiki
Line 78: Line 78:
== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
I'm investigating a few different approaches to doing this:
* as a GCC plugin
* as a patch to [http://clang-analyzer.llvm.org/ LLVM's static analysis tool] (packaged as part of llvm.src.rpm)
* using [https://sparse.wiki.kernel.org/index.php/Main_Page sparse]
* using CIL (see e.g. [http://berrange.com/posts/2009/05/15/static-analysis-to-validate-mutex-locking-in-libvirt-using-ocaml-cil/ the work we did to detect errors in libvirt]).
* using a Python library to parse C, e.g. [http://code.google.com/p/pycparser/ pycparser] or [https://launchpad.net/pyclibrary pyclibrary]


== Contingency Plan ==
== Contingency Plan ==

Revision as of 20:04, 25 April 2011


Static Analysis of CPython Extensions

Summary

I'm working on a static analysis tool that can detect common mistakes made in Python extension modules written in C. We'll run it on all such code in Fedora, fixing any problems we find, and send the patches to the appropriate upstream projects.

Owner

  • Email: dmalcolm@redhat.com

Current status

  • Targeted release: [[Releases/<number> | Fedora <number> ]]
  • Last updated: 2011-04-25
  • Percentage of completion: 5%


Detailed Description

Python makes it relatively easy to write wrapper code for C and C++ libraries, acting as a "glue" from which programs can be created.

Unfortunately, there are various mistakes that are commonly made in such wrapper code, and these mistakes can lead to /usr/bin/python leaking memory or segfaulting. There are other mistakes that only manifest as bugs when run on less common CPU architectures.

I'm working on static analysis code for C, to detect common errors in C extension modules for Python. The plan is to integrate this with Fedora's packaging, so that all C extension modules packaged for Python 2 and Python 3 can be guaranteed free of such errors (by adding hooks to the python-devel and python3-devel packages). We can also send fixes for this code as needed to upstream projects, when it reports problems.

For this to be viable, we'll need the tool to achieve a good signal:noise ratio.

Benefit to Fedora

Fedora is already a great environment for doing Python development - having a good-quality static analysis tool integrated into Fedora's build system for python extension modules will make Fedora even more compelling for Python developers. (Naturally the tool will be Free Software, and thus usable on other platforms; but we'll have it first).

The presence of the tool should also make it easier to fix certain awkward bugs, and make it easier to support secondary CPU architectures.

Scope

This involves:

  • writing the tool
  • ensuring that it works well on historical bugs (examples of real bugs that are now fixed)
  • tuning it to achieve a good signal:noise ratio:
    • testing it on everything in Fedora:
      • analyzing the issues that it reports
      • fixing bugs in the tool
      • fixing bugs in the software-under-test
      • generating a test suite for the tool
  • itegrating it into the python 2 and python 3 build of Fedora RPMs (python-devel and python3-devel)
  • ensuring that it does not substantially increase the time it takes to build the software-under-test
    • the selftest suite for the tool will need a performance component; we also need to be careful how we integrate it into Fedora's build system

How To Test

User Experience

Non-technical end-users of Fedora should see no difference (other than more a robust operating system).

Python users/developers should see additional warnings/errors when building Python extension modules that contain bugs. The exact experience will depend on how much we can be sure that an issue is a real problem; we don't want to impact the ability for people to do automated buildouts from PyPI.

Dependencies

I'm investigating a few different approaches to doing this:

Contingency Plan

There can be various levels of fallback:

  • the ability to set a flag in an rpm specfile that turns off testing for this rpm build
  • the ability to set a variable in the environment to suppress testing (perhaps this is the other way around: the extra tests are only run when a value is set)
  • (worst case) fully removing the testing hooks from python-devel and python3-devel if the feature proves problematic and is impeding getting the release out of the door.

I'm not yet sure what the structures of opt-in/opt-out and per-test/per-file/per-build should be.

Documentation

Release Notes

Comments and Discussion