This page stands for describing QA services.

• Test coverage reports

  Find HowTo pages.
  Find Result pages.
  Find older reports.
  

• QA Savannah report

  Find HowTo pages.
  Find web form page.
  

• QA Statistics report

  Find HowTo pages.
  

• Testing the QA reports

  To test the QA reports, check out the qmtest database from CVS.
  1. Set the CVSROOT environmment variable to :kserver:spi.cvs.cern.ch:/cvs/spi
  2. Check out the tests direcotry from CVS: cvs co Components/QA/Tools/tests
  3. Set the SPI environment by sourcing lcgspi.sh or lcgspi.csh, stored on AFS /afs/cern.ch/sw/lcg/app/spi/tools/latest/setup
  4. Run QMTest: qmtest -D your_directory/Components/QA/Tools/tests/config/qmtest run
  5. Visualize the results via your browser or command line : qmtest summarize results.qmr

     NB: QMTest is installed on AFS external.

• Profiling

  Find profiling tools available in SPI extsoft area.
  

  1. gprof

     • Compiling a Program for Profiling: compile and link your program with profiling enabled i.e. use -pg GCC flag.
       
     • Executing the Program: execute your program to generate a profile data file.
       
     • gprof Command Summary: run gprof to analyze the profile data.
       

       Also read GNU gprof page

  2. Valgrind

     Valgrind is a suite of tools for debugging and profiling Linux programs (x86-linux, amd64-linux) including three tools:
     • a memory error detectors,
     • a cache (time) profiler,
     • a heap (space) profiler
       
     Tool suites
     • Memcheck detects memory-management problems in your programs. All reads and writes of memory are checked, and calls to malloc/new/free/delete are intercepted. As a result, Memcheck can detect the following problems:
       • Use of uninitialised memory
       • Reading/writing memory after it has been free'd
         
       • Reading/writing off the end of malloc'd blocks
         
       • Reading/writing inappropriate areas on the stack
         
       • Memory leaks -- where pointers to malloc'd blocks are lost forever
         
       • Mismatched use of malloc/new/new [] vs free/delete/delete []
         
       • Overlapping src and dst pointers in memcpy() and related functions
         
       • Some misuses of the POSIX pthreads API
         
       • Problems like these can be difficult to find by other means, often lying undetected for long periods, then causing occasional, difficult-to-diagnose crashes.
         
     • Addrcheck is a lightweight version of Memcheck. It is identical to Memcheck except for the single detail that it does not do any uninitialised-value checks. All of the other checks -- primarily the fine-grained address checking -- are still done. The downside of this is that you don't catch the uninitialised-value errors that Memcheck can find.
       But the upside is significant: programs run about twice as fast as they do on Memcheck, and a lot less memory is used. It still finds reads/writes of freed memory, memory off the end of blocks and in other invalid places, bugs which you really want to find before release!
       Because Addrcheck is lighter and faster than Memcheck, you can run more programs for longer, and so you may be able to cover more test scenarios. Addrcheck was created because one of us (Julian) wanted to be able to run a complete KDE desktop session with checking. As of early November 2002, we have been able to run KDE-3.0.3 on a 1.7 GHz P4 with 512 MB of memory, using Addrcheck. Although the result is not stellar, it's quite usable, and it seems plausible to run KDE for long periods at a time like this, collecting up all the addressing errors that appear.
     • Cachegrind is a cache profiler. It performs detailed simulation of the I1, D1 and L2 caches in your CPU and so can accurately pinpoint the sources of cache misses in your code. If you desire, it will show the number of cache misses, memory references and instructions accruing to each line of source code, with per-function, per-module and whole-program summaries. If you ask really nicely it will even show counts for each individual machine instruction.
       On x86 and AMD64, Cachegrind auto-detects your machine's cache configuration using the CPUID instruction, and so needs no further configuration info, in most cases.
     • Helgrind finds data races in multithreaded programs. Helgrind looks for memory locations which are accessed by more than one (POSIX p-)thread, but for which no consistently used (pthread_mutex_)lock can be found. Such locations are indicative of missing synchronisation between threads, and could cause hard-to-find timing-dependent problems.