{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.<br/> '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.'''}}

−

−

{{admon/important | Set a Page Watch| Make sure you click ''watch'' on your new page so that you are notified of changes to it by others, including the Feature Wrangler}}

−

−

{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}

−

−

<!-- All fields on this form are required to be accepted by FESCo.

<!-- All fields on this form are required to be accepted by FESCo.

We also request that you maintain the same order of sections so that all of the feature pages are uniform. -->

We also request that you maintain the same order of sections so that all of the feature pages are uniform. -->

Line 25:

Line 18:

== Current status ==

== Current status ==

−

* Targeted release: [[Releases/<number> | Fedora <number> ]]

+

* Targeted release: [[Releases/16 | Fedora 16 ]]

−

* Last updated: 2011-04-25

+

* Last updated: 2011-07-26

−

* Percentage of completion: 5%

+

* Percentage of completion: either about 40% or 80% (see the following notes)

+

+

The code works, but only for checking Python's argument parsing API. This can detect real bugs, but the signal:noise ratio isn't great yet.

+

+

Having said that, automating reference-count checking is the really compelling aspect of this feature, and that part isn't yet ready. It works on various small examples, but there are plenty of examples of real code where it either crashes or gives misleading results. I want to work on fixing this, but at this stage I'm not going to get it into a shape where it's meaningful for 3rd-party testing by the 2011-07-26 deadline.

+

+

Given that, it may be worth either reducing the scope of this feature to the stuff that works, or postponing it to Fedora 17.

+

+

My preference is to postpone it to Fedora 17.

+

+

See the Fedora 17 continuation of this work: [[Features/StaticAnalysisOfPythonRefcounts|Static Analysis of Python Reference Counts]]

<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. -->

<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. -->

−

Python makes it relatively easy to write wrapper code for C and C++ libraries, acting as a "glue" layer to bind.

+

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, segfaulting, or failing when run on less common CPU architectures.

+

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). We can also send fixes for this code as needed to upstream projects, when it reports problems. (Naturally this assumes a good signal:noise ratio from the tool).

+

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. Part of this will need to involve having "good" error messages, spelling out how the problem occurs, what the impact is, and how to fix.

+

+

This will also benefit PyPy. PyPy has its own implementation of the CPython extension API, and certain bugs in extension code can lead to more severe symptoms with PyPy than with CPython. Specifically, [http://as.ynchrono.us/2011/04/pyopenssl-on-pypy.html some reference-counting bugs that are harmless on CPython can lead to segfaults of PyPy]. So by fixing these kinds of bug, we also help PyPy.

== Benefit to Fedora ==

== Benefit to Fedora ==

<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->

<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->

−

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.

+

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.

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

Line 49:

Line 56:

This involves:

This involves:

* writing the tool

* 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:

* tuning it to achieve a good signal:noise ratio:

−

** testing it on a large number of different extension modules

+

** testing it on everything in Fedora:

−

** analyzing the issues that it reports; fixing bugs in the

+

*** analyzing the issues that it reports

−

* itegrating it into the python 2 and python 3 build of Fedora RPMs (python-devel and python3-devel)

+

*** fixing bugs in the tool

+

*** fixing bugs in the software-under-test

+

*** generating a test suite for the tool

+

* integrating 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

+

The bugs I intend for the tool to detect are:

+

* ob_refcnt errors: missing Py_INCREF/Py_DECREF etc

+

* tp_traverse errors (which can mess up the garbage collector); missing it altogether, or omitting fields

"all in": turning it on by default, by adding the relevant compilation flags to sysconfig/distutils: <code>-fplugin=python2 -fplugin-arg-python2-script=PATH_TO_/cpychecker.py</code> so that all compilation using python-devel and python3-devel uses it, and providing flags to turn it off for when it's problematic.

+

+

"gcc-with-cpychecker": package it, leaving it optional, providing a <code>/usr/bin/gcc-with-cpychecker</code> wrapper script, to be invoked in place of gcc, so that people can opt in to using it.

+

+

In both cases, I plan to run all of the C Python extension code in Fedora 16 through it.

== How To Test ==

== How To Test ==

Line 69:

Line 94:

3. What are the expected results of those actions?

3. What are the expected results of those actions?

-->

-->

+

Exactly how to test will depend on which of the two approaches we go with (see "Scope" above)

+

+

Try to compile C Python extension code.

+

+

I'll provide an example of buggy extension code within the documentation part of the package, to make it easy to verify that GCC detects the bugs.

== User Experience ==

== User Experience ==

<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. -->

<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. -->

+

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.

+

+

For examples of the output from the checker, see:

+

http://dmalcolm.livejournal.com/6560.html

== 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 planning to do this via a [[Features/GccPythonPlugin|GCC plugin that embeds Python]], so that I can write the checker in Python itself.

+

+

FWIW I also investigated a few other approaches to doing this:

+

* 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 Coccinelle, like [http://dmalcolm.livejournal.com/3689.html my experiment on PyArg_ParseTuple from November 2009]

<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. -->

<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. -->

+

+

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 ==

== Documentation ==

<!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. -->

<!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. -->

<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->

<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->

<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->

<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->

−

*

+

Fedora now ships with a <code>gcc-with-cpychecker</code> variant of GCC, which adds additional compile-time checks to Python extension modules written in C, detecting various common problems (e.g. reference counting mistakes). This variant is itself written in Python.

== Comments and Discussion ==

== Comments and Discussion ==

−

* See [[Talk:Features/YourFeatureName]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->

+

* See [[Talk:Features/StaticAnalysisOfCPythonExtensions]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->

−

[[Category:FeaturePageIncomplete]]

+

[[Category:FeatureAcceptedF16]]

<!-- When your feature page is completed and ready for review -->

<!-- When your feature page is completed and ready for review -->

<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->

<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->

<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->

<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->

<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

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.

Percentage of completion: either about 40% or 80% (see the following notes)

The code works, but only for checking Python's argument parsing API. This can detect real bugs, but the signal:noise ratio isn't great yet.

Having said that, automating reference-count checking is the really compelling aspect of this feature, and that part isn't yet ready. It works on various small examples, but there are plenty of examples of real code where it either crashes or gives misleading results. I want to work on fixing this, but at this stage I'm not going to get it into a shape where it's meaningful for 3rd-party testing by the 2011-07-26 deadline.

Given that, it may be worth either reducing the scope of this feature to the stuff that works, or postponing it to Fedora 17.

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. Part of this will need to involve having "good" error messages, spelling out how the problem occurs, what the impact is, and how to fix.

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.

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

integrating 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

The bugs I intend for the tool to detect are:

ob_refcnt errors: missing Py_INCREF/Py_DECREF etc

tp_traverse errors (which can mess up the garbage collector); missing it altogether, or omitting fields

errors in PyArg_ParseTuple and friends (often leads to flaws on big-endian 64-bit architectures)

There are two approaches to integrating it:

"all in": turning it on by default, by adding the relevant compilation flags to sysconfig/distutils: -fplugin=python2 -fplugin-arg-python2-script=PATH_TO_/cpychecker.py so that all compilation using python-devel and python3-devel uses it, and providing flags to turn it off for when it's problematic.

"gcc-with-cpychecker": package it, leaving it optional, providing a /usr/bin/gcc-with-cpychecker wrapper script, to be invoked in place of gcc, so that people can opt in to using it.

In both cases, I plan to run all of the C Python extension code in Fedora 16 through it.

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.

Fedora now ships with a gcc-with-cpychecker variant of GCC, which adds additional compile-time checks to Python extension modules written in C, detecting various common problems (e.g. reference counting mistakes). This variant is itself written in Python.