Presentation is loading. Please wait.

Presentation is loading. Please wait.

(Static) Program Analysis 동아대학교 컴퓨터공학과 조장우. Motivation u 컴퓨터 기술자는 무엇을 해야 하는가 ? The production of reliable software, its maintenance, and safe evolution.

Similar presentations


Presentation on theme: "(Static) Program Analysis 동아대학교 컴퓨터공학과 조장우. Motivation u 컴퓨터 기술자는 무엇을 해야 하는가 ? The production of reliable software, its maintenance, and safe evolution."— Presentation transcript:

1 (Static) Program Analysis 동아대학교 컴퓨터공학과 조장우

2 Motivation u 컴퓨터 기술자는 무엇을 해야 하는가 ? The production of reliable software, its maintenance, and safe evolution year after year (up to 20 to 30 years)

3 Hardware and Software uHardware Over the last 25 years, computer hardware has seen its performance multiplied by 10 6; uSoftware The size of programs executed by these computers has grown up in similar proportions; uExample MS Windows – > 30 000 000 lines – > 30 000 known bugs

4 Software Development uSoftware development Large scale computer programming is very difficult; Reasoning on large programs is very difficult; Errors are quite frequent uIdea Use the computer to find programming errors How can computers be programmed so as to analyze the behavior of software before and without executing it? This is essential for safety-critical systems (eg. planes, trains, launchers, nuclear plants, …)

5 Program Analysis u 프로그램의 실행 성질을 실행 전에 자동으로 안전하게 어림잡는 기술이다 [ 이광근 04]. 실행 전에 : 프로그램을 실행시키지 않고 자동으로 : 프로그램이 프로그램을 분석 안전하게 : 모든 가능성을 포함하도록 어림잡는 : 실제 이외의 것들이 포함됨 어림잡지 않으면 불가능

6 Program Analysis vs Testing uTesting To prove the presence of bugs relative to a specification; Some bugs may be missed; Nothing can be concluded on correctness when no bug is found uProgram analysis To prove the absence of bugs relative to a specification; No bugs is ever missed; Inconclusive situations may exist(undecidability) -> bug or false alarm Correctness follows when no bug is found;

7 Program Analysis Techniques uData Flow Analysis uConstraint based analysis uType based analysis Type and effect system Type qualifier uAbstract interpretation uModel checking …

8 Questions about behavior of programs Is the variable x initialized before it is read? Will the value of x be read in the future? What is a lower and upper bound on the value of the integer variable x? At which program points could x be assigned its current value? Can the pointer p be null? Which variables can p point to? Do p and q point to disjoint structures in the heap? …

9 Why are the answers interesting? uEnsure correctness Verify behavior Catch bugs early uIncrease efficiency Compiler optimization Resource usage

10 Rice’s theorem, 1953 uAny non trivial property of the behavior of programs in a Turing-complete language is undecidable! uCan we decide if a variable has a constant value?

11 Approximation uApproximate answers may be decidable! uThe approximation must be conservative: either ”yes” or ”no” must always be the correct answer which direction depends on the client application the useful answer must always be correct

12 Example approximations uDecide if a function is ever called at runtime: if ”no”, remove the function from the code if ”yes”, don’t do anything the ”no” answer must always be correct if given uDecide if a cast (A)x will always succeed: if ”yes”, don’t generate a runtime check if ”no”, generate code for the cast the ”yes” answer must always be correct if given

13 The engineering challenge uA correct but trivial approximation algorithm may just give the useless answer every time uThe engineering challenge is to give the useful answer often enough to fuel the client application uThis is the hard (and fun) part of static analysis...

14 Engineering in practice (1/4) Where do the pointers come from?

15 Engineering in practice (2/4) The trivial answer: from somewhere!

16 Engineering in practice (3/4) The hard answer: from a few places!

17 Engineering in practice (4/4) Over the last 15 years:  ≥ 500 publications, ≥ 50 PhD theses

18 Bug finding int main() { char *p,*q; p = NULL; printf("%s",p); q = (char *)malloc(100); p = q; free(q); *p = 'x'; free(p); p = (char *)malloc(100); q = p; strcat(p,q); }

19 Industrialization uFortify (2003, USA) Merged into HP, 2010 uPolyspace(1999, France) Abstract interpretation based tool. uSparrow(2007, Korea) u… Buffer overrun, null dereference, use after free, double free, free non-heap variable, memory leaks, divide by zero, …

20 Q & A


Download ppt "(Static) Program Analysis 동아대학교 컴퓨터공학과 조장우. Motivation u 컴퓨터 기술자는 무엇을 해야 하는가 ? The production of reliable software, its maintenance, and safe evolution."

Similar presentations


Ads by Google