A Bug’s Life (ABL) Julia Lawall (Inria/LIP6-Regal) Gilles Muller (Inria/LIP6-Regal) Software has bugs! Our target: Large, open-source infrastructure software • Low-level, multifunctional code • Widely dispersed developers • Examples: The Linux kernel, the Python runtime, etc. Challenges: • What code is fault prone? • How to find faults? What code is fault prone? Case study: The Linux kernel. Prior hypotheses: • Linux is large, growing, and full of faults. • Device drivers are of low quality. • Results of Chou et al. [SOSP 2001] Results: Code size 8 6 4 2 Other 2.4.0 Drivers/Staging 2.4.1 Arch Drivers w/o Staging 2.5.0 File Systems (FS) Net 2.2.0 Sound 2.3.0 1.0 2.0 1.2.0 2.1.0 2.6.28 2.6.12 2.6.0 0 10 20 09 20 08 20 07 20 06 20 05 20 04 20 03 20 02 20 01 20 00 20 99 19 98 19 97 19 96 19 95 19 94 19 Results: Fault rate % of faulty notes 0.8 Average Staging Drivers Sound Arch FS Net Other 0.6 0.4 0.2 0.0 2004 2005 2006 2007 2008 2009 2010 How to find faults? Case study: Memory leaks. Prior hypotheses: • Effective to focus on common function pairs. – malloc/free, open/close • The basis of many approaches [ICSE, SOSP, PLDI, etc]. Results Hector: Memory leak detection based on function-local information. • 371 faults found in Linux, Python runtime, etc. • False positive rate: 23%. Support Results Pairs having support >= 15 and confidence >= 90% Other protocols False Positives 1000 100 10 1 0 10 20 30 40 50 60 Confidence (%) 70 80 90 100 Conclusion • A need for bottom-up investigation. – From raw data to methodologies. – Lots of data available: code, patches, mailing lists, etc. • A need for continuous reassessment of priorities. – Open source analysis tools and methodologies. – Allow experiments to be repeated.