Data Structure Repair Using Goal-Directed Reasoning

Data Structure Repair Using Goal-Directed Reasoning

Télécharger la présentation

Data Structure Repair Using Goal-Directed Reasoning

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

1. Data Structure Repair Using Goal-Directed Reasoning Brian Demsky Martin Rinard Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology

2. Problem Broken Data Structure Errors • Missing elements • Inappropriate sharing • Dangling references • Out of bounds array indices • Inconsistent values F = 20 G = 10 F = 20 G = 5 I = 5 J = 2

3. Solution Broken Data Structure Consistent Data Structure F = 20 G = 10 F = 2 G = 1 F = 10 G = 5 F = 20 G = 10 F = 20 G = 5 Repair Algorithm I = 3 I = 5 J = 2 J = 2

4. OOPSLA 2003 Broken Abstract Model Repaired Abstract Model Abstract Repair Model Definition Rules External Consistency Constraints 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Broken Bits Repaired Bits

5. ICSE 2005 (this paper) Broken Abstract Model Repaired Abstract Model Abstract Repair Model Definition Rules External Consistency Constraints 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Broken Bits Repaired Bits

6. Why Eliminate External Consistency Constraints? • Development overhead of external consistency constraints • Possibility of errors in the external consistency constraints • Difficulties ensuring that repaired model corresponds to a concrete data structure

7. How Did We Do It? Goal-directed reasoning replaces external consistency constraints • Start with repair that makes model consistent • Goal: implement this repair in data structures • Reasoning: analyze model definition rules • Result: data structure updates that implement abstract repairs

8. Result Broken Abstract Model Repaired Abstract Model Abstract Repair Model Definition Rules External Consistency Constraints 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Broken Bits Repaired Bits

9. Result Broken Abstract Model Repaired Abstract Model Abstract Repair Model Definition Rules External Consistency Constraints 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Automatically Generated Concrete Data Structure Updates Broken Bits Repaired Bits

10. struct disk { int blockbitmap; entry dir[numentries]; block block[numblocks]; } struct entry { byte name[Length]; int firstblock; } File System Example -5 intro 2 -1 -1 3 -1 Directory Entries Disk Blocks struct block { int nextblock; byte data[blocksize]; } struct blockbitmap subtype block { int nextblock; bit bitmap[numblocks]; }

11. File System Model Block • Sets of objects set Block of block : Used | Free set Used of block : Bitmap • Relations between objects relation Next : Used, Used relation BlockStatus : Block, boolean BlockStatus Next boolean Used Free Bitmap

12. Model Translation Bits translated to sets and relations in abstract model using statements of the form: Quantifiers, Condition => Inclusion Constraint i  [0..numentries-1], 0  d.dir[i].firstblock  d.block[d.dir[i].firstblock] Used b Used, 0  b.nextblock  b,d.block[b.nextblock]Next b Used, 0  b.nextblock  d.block[b.nextblock] Used b in [0..numblocks-1], d.block[b] Used d.block[b]Free true  d.block[d.blockbitmap]  Bitmap j  [0..numblocks-1], b Bitmap, true => <d.block[j],b.bitmap[j]> BlockStatus

13. Model for File System Example -5 intro 2 -1 -1 3 -1 Directory Entries Disk Blocks Blocks Used 2 3 Free Next 1 0 Bitmap

14. Consistency Constraints in Example |Bitmap|=1 u Used, u.BlockStatus=true f Free, f.BlockStatus=false b Used, |Next.b|  1 Blocks Used 2 3 Free Next 1 0 Bitmap

15. Detecting Inconsistencies Evaluate consistency properties, find violations |Bitmap|=1 is violated - Bitmap set is empty Blocks Used 2 3 Free Next 1 0 Bitmap

16. Repairing Violations of Model Consistency Properties • Violation provides binding for quantified variables • Convert Body to disjunctive normal form (p1  …  pn )  …  (q1  …  qm ) p1 …pn , q1 …qm are basic propositions • Choose a conjunction to satisfy • Repair violated basic propositions in conjunction

17. Repairing Violations of Basic Propositions • Inequality constraints on values of numeric fields • V.R = E, V.R < E, V.R  E, V.R  E, V.R > E • Compute value of expression, assign relation • Presence of required number of objects • |S| = C, |S|  C, |S|  C • Remove or insert objects from/to set • Topology of region surrounding each object • |V.R| = C, |V.R|  C, |V.R|  C • |R.V| = C, |R.V|  C, |R.V|  C • Remove or insert tuples from/to relation • Inclusion constraints: V in S, V1 in V2.R, V1,V2 in R • Remove or add the object or tuple from/to set or relation

18. Repairing Inconsistencies Repair the violation of |Bitmap|=1 by adding a block to the Bitmap set Blocks Used 2 3 Free Next 1 0 Bitmap

19. Goal-Directed Reasoning Translates Abstract Repairs Into Concrete Repairs • Abstract repairs add or remove objects (or tuples) to sets (or relations) • Goal: find concrete data structure updates with same effect • Find model definition rules that construct the relevant set or relation • Basic strategy: For removals, appropriately falsify the guards of all these model definition rules. For additions, appropriately satisfy the guard of one of these model definition rules.

20. Goal-Directed Reasoning in Example • Abstract Repair: add block 0 to the Bitmap set

21. Goal-Directed Reasoning in Example • Abstract Repair: add block 0 to the Bitmap set • Model Definition Rules: i  [0..numentries-1], 0  d.dir[i].firstblock  d.block[d.dir[i].firstblock] Used b Used, 0  b.nextblock  b,d.block[b.nextblock]Next b Used, 0  b.nextblock  d.block[b.nextblock] Used b in [0..numblocks-1], d.block[b] Used d.block[b]Free true  d.block[d.blockbitmap]  Bitmap j  [0..numblocks-1], b Bitmap, true => <d.block[j],b.bitmap[j]> BlockStatus

22. Goal-Directed Reasoning in Example • Abstract Repair: add block 0 to the Bitmap set • Model Definition Rules: i  [0..numentries-1], 0  d.dir[i].firstblock  d.block[d.dir[i].firstblock]  Used b  Used, 0  b.nextblock  b,d.block[b.nextblock] Next b  Used, 0  b.nextblock  d.block[b.nextblock]  Used b in [0..numblocks-1], d.block[b]  Used d.block[b] Free true  d.block[d.blockbitmap]  Bitmap j  [0..numblocks-1], b  Bitmap, true => <d.block[j],b.bitmap[j]>  BlockStatus

23. Goal-Directed Reasoning in Example • Abstract Repair: add block 0 to the Bitmap set • Relevant Model Definition Rule: true  d.block[d.blockbitmap]  Bitmap • d.block[d.blockbitmap]=block 0

24. Goal-Directed Reasoning in Example • Abstract Repair: add block 0 to the Bitmap set • Relevant Model Definition Rule: true  d.block[d.blockbitmap]  Bitmap • d.block[d.blockbitmap]=block 0 • Data Structure Update: d.blockbitmap = index of block 0 in d.block array

25. Repair in Example Original File System -5 intro 2 -1 -1 3 -1 Directory Entries Disk Blocks Updated File System 0 intro 2 -1 -1 3 -1 block bitmap Directory Entries Disk Blocks

26. Reasoning at Compile Time • Compile specifications into repair algorithms • Goal-directed reasoning takes place at compile time • Consider possibility that |Bitmap| = 0 • Abstract repair • Choose a block in Free set • Add block to Bitmap set • Concrete repair • Find relevant model definition rule: true  d.block[d.blockbitmap]  Bitmap • Goal-directed reasoning finds following update: d.blockbitmap = index of block in d.block array • Check that block is an element of d.block array: b in [0..numblocks-1], d.block[b] Used d.block[b]Free

27. Multiple Repairs • Some broken data structures may require multiple repairs • Reconstruct model • Reevaluate consistency constraints • Perform any required additional repairs

28. Architecture Broken Abstract Model Repaired Abstract Model Abstract Repair . . . . Model Translation 10111001011 10101011101 10101110110 01011001011 10101011101 10101110110 00011001011 10101011101 10101110110 . . . . Automatically Generated Concrete Repair Broken Bits Repaired Bits

29. Model Recomputation BlockStatus Blocks true Used 3 2 Free Next false 1 Bitmap 0

30. Model Recomputation Re-evaluate constraints, find violations of u Used, u.BlockStatus=true and f Free, f.BlockStatus=false BlockStatus Blocks true Used 3 2 Free Next false 1 Bitmap 0

31. Model Recomputation Repair violations of u Used, u.BlockStatus=true and f Free, f.BlockStatus=false by modifying the BlockStatus relation BlockStatus Blocks true Used 3 2 Free Next false 1 Bitmap 0

32. Repaired File System Repaired File System 0 intro 2 1011 -1 -1 3 -1 block bitmap Directory Entries Disk Blocks

33. Acyclic Repair Dependences • Questions • Isn’t it possible for the repair of one constraint to invalidate another constraint? • What about infinite repair loops? • What about unsatisfiable specifications? • Answer • We require specifications to have no cyclic repair dependences between constraints • So all repair sequences terminate • Repair can fail only because of resource limitations

34. Repair Dependence Graph 4. Satisfy Rule 6 (BlockStatus) 1. |Bitmap|=1 2. Add block to Bitmap 5. f.BlockStatus=false 3. d.blockbitmap=indexof(bfree) 6. Replace <f,true> with <f,false> in BlockStatus 8. Remove <f,true> from BlockStatus by removing Bitmap 7. b.bitmap[j]=false for j=indexof(f)

35. Repair Dependence Graph 4. Satisfy Rule 6 (BlockStatus) 1. |Bitmap|=1 2. Add block to Bitmap 5. f.BlockStatus=false 3. d.blockbitmap=indexof(bfree) 6. Replace <f,true> with <f,false> in BlockStatus 8. Remove <f,true> from BlockStatus by removing Bitmap 7. b.bitmap[j]=false for j=indexof(f)

36. Repair Dependence Graph 4. Satisfy Rule 6 (BlockStatus) 1. |Bitmap|=1 2. Add block to Bitmap 5. f.BlockStatus=false 3. d.blockbitmap=indexof(bfree) 6. Replace <f,true> with <f,false> in BlockStatus 7. b.bitmap[j]=false for j=indexof(f)

37. When to Test for Consistency and Repair • Persistent data structures • Repair can be independent activity, or • Repair when data written out or read in • Volatile data structures in running program • Under programmer control • Transaction-based approach • Identify transaction start and end • Repair at start, end, or both • Failure-based approach • Wait until program fails • Repair and restart from latest safe point

38. Experience • We acquired five benchmarks (written in C/C++) • AbiWord • x86 emulator • CTAS (air-traffic control tool) • Simplified Linux file system • Freeciv interactive game • We developed specifications for all five • Little development time (days, not weeks) • Most of time spent figuring out Freeciv and CTAS • Each benchmark has • Workload • Bug or fault insertion methodology • Ran benchmarks with and without repair

39. AbiWord • Open-source word processing program • Approximately 360,000 lines of C++ code • Abiword represents documents using a Piece table • Consistency properties: • Piece table has a section fragment • Piece table has a paragraph fragment • Doubly-linked list of fragments is well formed

40. AbiWord Screen Shot

41. Results • Workload – import (valid) Microsoft Word document that crashes AbiWord • Bug that creates inconsistent documents with a text fragment before the section fragment • Without repair • AbiWord crashes when loading the document • With repair • AbiWord is able to open and successfully process the document

42. Parallel x86 emulator • Parallel x86 emulator for the RAW machine • Multi-tile architecture • Emulator runs x86 binaries on RAW • Contains L2 cache of translated x86 assembly instructions • Maintains a constant L2 cache size • Consistency property: • Computed size of the L2 cache is consistent with its actual size

43. Results • Workload – gzip benchmark on x86 emulator • Bug that (sometimes) adds the size of a cache item twice when it is inserted • Without repair • Actual cache size goes to zero • x86 emulator crashes • With repair • Actual cache size is the same as computed size • Program runs correctly

44. CTAS • Set of air-traffic control tools • Traffic management • Arrival planning • Flow visualization • Shortcut planning • Deployed in centers around country (Dallas/Ft. Worth, Los Angeles, Denver, Miami, Minneapolis/St. Paul, Atlanta, Oakland) • Approximately 1 million lines of C/C++ code

45. CTAS Screen Shot

46. Results • Workload – recorded radar feed from DFW • Fault insertion • Simulate error in flight plan processing • Bad airport index in flight plan data structure • Without repair • System crashes – segmentation fault • With repair • Aircraft has different origin or destination • System continues to execute • Anomaly eventually flushed from system

47. Aspects of CTAS • Lots of independent subcomputations • System processes hundreds of aircraft – problem with one should not affect others • Multipurpose system (visualization, arrival planning, shortcuts, …) – problem in one purpose should not affect others • Sliding time window: anomalies eventually flushed • Rebooting ineffective – system will crash again as soon as it sees the problematic flight plan

48. Simplified Linux File System intro 0 110 1011 directory block super block group block inode bitmap block block bitmap block inode … inode disk blocks inode block Some Consistency Properties • inode bitmap consistent with inode usage • block bitmap consistent with block usage • directory entries refer to valid inodes • files contain valid blocks only • files do not share blocks

49. Results • Workload – write and verify several files • Simulated power failure • Inode and block bitmap errors • Partially initialized directory and inode entries • Without repair • Incorrect file contents because of inode and disk block sharing • With repair • Bitmaps repaired preventing illegal sharing, correct file contents

50. Freeciv Terrain Grid O = Ocean Consistency Properties • Tiles have valid terrain values • Cities are not in the ocean • Each city has exactly one reference from the grid O P M M P = Plain O O P M M = Mountain O P M M City Structures P P P M