[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

In the topic of *code analysis* or *program analysis* ([[!wikipedia
Program_analysis_(computer_science) desc="Wikipedia article"]]), there is
static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia
article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis
desc="Wikipedia article"]]).  This topic overlaps with [[performance
analysis|performance]], [[formal_verification]], as well as general
[[debugging]].

[[!toc]]


# Bounty

There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.


# Static

  * [[GCC]]'s warnings.  Yes, really.

      * GCC plugins can be used for additional semantic analysis.  For example,
        <http://lwn.net/Articles/457543/>, and search for *kernel context* in
        the comments.

      * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out*
        specifiers, and have it emit useful warnings in case these are pointing
        to uninitialized data (for *in* only).

  * [[!wikipedia List_of_tools_for_static_code_analysis]]

  * [Engineering zero-defect software](http://esr.ibiblio.org/?p=4340), Eric
    S. Raymond, 2012-05-13

  * [Static Source Code Analysis Tools for C](http://spinroot.com/static/)

  * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/)

    For example, [Debian's hurd_20110319-2
    package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html)
    (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious;
    the realloc issues are for real*).

  * Coccinelle

      * <http://lwn.net/Articles/315686/>

      * <http://www.google.com/search?q=coccinelle+analysis>

  * [clang](http://www.google.com/search?q=clang+analysis)

  * [Linux' sparse](https://sparse.wiki.kernel.org/)

  * <http://klee.llvm.org/>

      * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>

  * [Smatch](http://smatch.sourceforge.net/)

  * [Parfait](http://labs.oracle.com/projects/parfait/)

      * <http://lwn.net/Articles/344003/>

  * [Saturn](http://saturn.stanford.edu/)

  * [Flawfinder](http://www.dwheeler.com/flawfinder/)

  * [sixgill](http://sixgill.org/)

  * [s-spider](http://code.google.com/p/s-spider/)

  * [CIL (C Intermediate Language)](http://kerneis.github.com/cil/)

  * [Frama-C](http://frama-c.com/)

  * [Coverity](http://www.coverity.com/) (nonfree?)

  * [Splint](http://www.splint.org/)

      * IRC, freenode, #hurd, 2011-12-04

            <mcsim> has anyone used splint on hurd?
            <mcsim> this is tool for statically checking C programs
            <mcsim> seems I made it work


## Hurd-specific Applications

  * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]].  If
    these are used, care must be taken to update them reliably, [[!message-id
    "1123688017.3905.22.camel@buko.sinrega.org"]].  This could be checked by a
    static analysis tool.

  * [[glibc]]'s [[glibc/critical_section]]s.


# Dynamic

  * [[community/gsoc/project_ideas/Valgrind]]

  * glibc's `libmcheck`

      * Used by GDB, for example.

      * Is not thread-safe, [[!sourceware_PR 6547]], [[!sourceware_PR 9939]],
        [[!sourceware_PR 12751]], [[!stackoverflow_question 314931]].

  * <http://en.wikipedia.org/wiki/Electric_Fence>

      * <http://sourceforge.net/projects/duma/>

  * <http://wiki.debian.org/Hardening>

  * <https://wiki.ubuntu.com/CompilerFlags>

  * `MALLOC_CHECK_`/`MALLOC_PERTURB_`

      * IRC, freenode, #glibc, 2011-09-28

            <vsrinivas> two things you can do -- there is an environment
              variable (DEBUG_MALLOC_ iirc?) that can be set to 2 to make
              ptmalloc (glibc's allocator) more forceful and verbose wrt error
              checking
            <vsrinivas> another is to grab a copy of Tor's source tree and copy
              out OpenBSD's allocator (its a clearly-identifyable file in the
              tree); LD_PRELOAD it or link it into your app, it is even more
              aggressive about detecting memory misuse.
            <vsrinivas> third, Red hat has a gdb python plugin that can
              instrument glibc's heap structure. its kinda handy, might help?
            <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry.

      * [`MALLOC_PERTURB_`](http://udrepper.livejournal.com/11429.html)

      * <http://git.fedorahosted.org/cgit/initscripts.git/diff/?id=deb0df0124fbe9b645755a0a44c7cb8044f24719>

  * In context of [[!message-id
    "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue
    mentioned in [[gnumach_page_cache_policy]]:

    IRC, freenode, #hurd, 2012-07-08:

        <youpi> braunr: there's actually already an ifdef REDZONE in libthreads

    It's `RED_ZONE`.

        <youpi> except it seems clumsy :)
        <youpi> ah, no, the libthreads code properly sets the guard, just for
          grow-up stacks

  * GCC's AddressSanitizer, a memory error detector (ASan;
    `-fsanitize=address`)

    [Finding races and memory errors with GCC instrumentation
    (AddressSanitizer)](http://gcc.gnu.org/wiki/cauldron2012#Finding_races_and_memory_errors_with_GCC_instrumentation_.28AddressSanitizer.29),
    GNU Tools Cauldron 2012.  <http://code.google.com/p/address-sanitizer/>.

    Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]].

  * GCC's ThreadSanitizer, a data race detector (TSan; `-fsanitize=thread`)

    <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer>

    Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]].

  * [GCC plugins](http://gcc.gnu.org/wiki/plugins)

      * [CTraps](https://github.com/blucia0a/CTraps-gcc)

        > CTraps is a gcc plugin and runtime library that inserts calls to runtime
        > library functions just before shared memory accesses in parallel/concurrent
        > code.
        > 
        > The purpose of this plugin is to expose information about when and how threads
        > communicate with one another to programmers for the purpose of debugging and
        > performance tuning.  The overhead of the instrumentation and runtime code is
        > very low -- often low enough for always-on use in production code.  In a series
        > of initial experiments the overhead was 0-10% in many important cases.

  * Input fuzzing

    Not a new topic; has been used (and papers published?) for early [[UNIX]]
    tools.  What about some [[RPC]] fuzzing?

      * <http://caca.zoy.org/wiki/zzuf>

      * <http://www.ece.cmu.edu/~koopman/ballista/>

      * [Jones: system call abuse](http://lwn.net/Articles/414273/), Dave
        Jones, 2010.

          * [Trinity: A Linux kernel fuzz tester (and then
            some)](http://www.socallinuxexpo.org/scale11x/presentations/trinity-linux-kernel-fuzz-tester-and-then-some),
            Dave Jones, The Eleventh Annual Southern California Linux Expo, 2013.