In the topic of code analysis or program analysis (Wikipedia article), there is static code analysis (Wikipedia article) and dynamic program analysis (Wikipedia article). This topic overlaps with performance analysis, formal verification, as well as general debugging.

Bounty

There is a FOSS Factory bounty (p276) 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/MIG in/out specifiers, and have it emit useful warnings in case these are pointing to uninitialized data (for in only).

• List of tools for static code analysis

• Engineering zero-defect software, Eric S. Raymond, 2012-05-13

• Static Source Code Analysis Tools for C

• Cppcheck

  For example, Debian's hurd_20110319-2 package (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

  Has already been used for finding and fixing double mutex unlocking issues.

• clang

• Linux' sparse

• http://klee.llvm.org/

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

• Smatch

• Parfait

  • http://lwn.net/Articles/344003/

• Saturn

• Flawfinder

• sixgill

• s-spider

• CIL (C Intermediate Language)

• Frama-C

• Coverity (nonfree?)

• Splint

  • 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. If these are used, care must be taken to update them reliably, id:"1123688017.3905.22.camel@buko.sinrega.org". This could be checked by a static analysis tool.

• glibc's critical sections.

Dynamic

• Valgrind

• glibc's libmcheck

  • Used by GDB, for example.

  • Is not thread-safe, sourceware [BZ #6547], sourceware [BZ #9939], sourceware [BZ #12751], Stack Overflow 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://git.fedorahosted.org/cgit/initscripts.git/diff/?id=deb0df0124fbe9b645755a0a44c7cb8044f24719

• In context of 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, LLVM/clang: Address Sanitizer (asan), Memory Sanitizer (msan), Thread Sanitizer (tasn), Undefined Behavor Sanitizer (ubsan), ...

• GCC plugins

  • CTraps

    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, Dave Jones, 2010.

    • Trinity: A Linux kernel fuzz tester (and then some), Dave Jones, The Eleventh Annual Southern California Linux Expo, 2013.