1. Code improvement: Coverity static analysis Valgrind dynamic analysis GABRIELE COSMO CERN, EP/SFT

2. Outline Code static analysis with Coverity ◦How to “triage” defects ◦Current status of Static Code Analysis Code dynamic analysis with Vagrind ◦Run-time errors checks ◦Keeping memory leaks under control 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 2

3. Coverity Static Code Analysis Inspecting only the source code ◦Execution by replacing the compiler Analysis performed on all possible branches of the code ◦Complex and time consuming Identifies defects in the code ◦organizes by type, severity, file/module Results published on Coverity server at CERN ◦https://coverity.cern.ch 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 3

4. Coverity: triaging defects  According to the action, the defect is marked as “triaged”  Statistics will be updated  Defects fixed in the code will automatically disappear from the defects lists, even if never triaged in the tool  Defects not fixed will show up again at the next analysis 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 4 Defects are assigned to responsible (owner) The owner can classify a defect as:  Pending / False positive / Intentional / Bug Can assess and specify the severity:  Major, Moderate, Minor Can specify an action (performed or to be performed):  Fix required, Fix submitted, Modeling required, Ignore

5. Coverity: defects types ◦Memory corruption / illegal accesses ◦Double free, out-of-bound accesses, use-after-delete, … ◦Resource leaks ◦Non virtual destructor, memory leaks, … ◦Uninitialized variables, Unused pointer values, Infinite loops, Missing copy ctors, … ◦API usage errors ◦Non restoring ostream format, use of invalid iterator, … ◦Control flow issues ◦Unused/dead code, invalid iterator comparisons, … ◦Incorrect expressions ◦Self-assignment, misuse of enumerators, divisions by zero, … ◦Code organization / performance inefficiencies ◦Recursive headers, hidden parameters, big parameters passed by value, … ◦Security best practices violations  All defect kinds provided with online documentation 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 5

6. Use of Coverity in Geant4 New static analysis done after every reference tag ◦Results published immediately after ◦Notification sent to all Category coordinators and to individual developers owning outstanding defects Static analysis applied for all Geant4 libraries ◦Including all possible visualization drivers and optional modules ◦Applied to either sequential or MT mode ◦Could be automated (still requiring manual intervention for assigning owners) & eventually applied as separate module also to examples/tests 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 6

7. Current status in Geant4 Coverity tool introduced to the Collaboration at the 2010 Geant4 Workshop ◦First analysis (before tool upgrades) reported a total of 2753 outstanding defects ◦Status on last reference tag (10-02-ref-08): ◦Outstanding defects: 181 (of which, 167 never triaged) ◦Resolved defects: 3630 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 7 Goal: ZERO outstanding defects !!!

8. Coverity: outstanding defects Uninitialized data in constructor: 54 (50) Memory leak: 26 (25) Unreachable or dead code: 23 (22) Dereferencing of NULL pointer: 19 (18) Unchecked return value: 8 (8) Negative index to vector: 7 (7) Constructor-destructor leak: 7 (3) Stream format state: 7 (6) Out-of-bounds read: 6 (6) 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 8 Uninitialized scalar value: 3 (3) Null return value dereferenced: 3 (3) Unused value: 3 (3) Missing break in switch: 3 (3) Constant expression / wrong operator: 2 (2) Invalid iterator: 2 (2) Null check after dereferencing: 2 (2) Use after free: 1 (1) Copy & paste error: 1 (0)

9. Valgrind 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 9

10. Use of Valgrind in Geant4 Selected examples/tests executed for candidate releases and selected reference releases ◦Results published and distributed to Category Coordinators and relevant developers Checks for memory leaks in event loop ◦Can only be done manually until all leaks (including those at initialisation, or from examples/tests) are not fixed ◦Requires two runs with different statistics and manual comparison of results Run-time errors checks ◦Now part of regular system testing 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 10

11. Valgrind DRD tool Data Race Detection tool ◦Included in the Valgrind suite (use with –tool=drd) ◦Used by some developers only when necessary… ◦Would be nice to include it as part of regular system testing for MT runs Different types of errors detected: ◦Data races (unprotected possible access to shared resources) ◦Lock contention (checks Mutex locked for too long) ◦Misuse of POSIX threads ◦e.g. attempt to unlock a Mutex that was not locked,… 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 11

12. Conclusions Coverity static analyzer and Valgrind tools regularly used in our development process Drastically reduced reported defects since first introduction of Coverity in 2010 ◦Important to keep going fixing defects and monitoring! ◦Tool also extremely useful in detecting memory leaks and run-time memory errors Use of Valgrind made for memory checks and MT race condition checks ◦Checks for memory leaks can be automated only if leak-free tests are achieved 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 12

13. Thanks! 14 September 2016G.COSMO - CODE IMPROVEMENT: COVERITY & VALGRIND 13