A Bug’s Life (ABL) Julia Lawall (Inria/LIP6-Regal) Gilles Muller (Inria/LIP6-Regal)

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.