1 / 63

Data Structure Repair Using Goal-Directed Reasoning

Data Structure Repair Using Goal-Directed Reasoning. Brian Demsky Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology. Motivation. Broken Data Structure. Errors Missing elements Inappropriate sharing Dangling references

jmorse
Télécharger la présentation

Data Structure Repair Using Goal-Directed Reasoning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Motivation 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. Goal 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. Goal Broken Data Structure Consistency Properties From Developer 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

  5. What Does Repair Algorithm Produce? • Data structure that • Satisfies consistency properties, and • Heuristically close to broken data structure • Not necessarily the same data structure as (hypothetical) correct program would produce • But enough to keep program operating successfully

  6. Where Is This Likely To Be Useful? • Less useful when acceptable to reboot • Must be OK to lose volatile state • Must be OK to wait for reboot • Cause of error must go away after reboot • Persistent data structures (file systems, application files) • Autonomous and/or safety critical systems • Monitor/control unstable physical phenomena • Largely independent subcomputations • Moving time window

  7. Basic Approach Broken Abstract Model Repaired Abstract Model Abstract Repair Model Translation 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Automatically Generated Concrete Repair Broken Bits Repaired Bits

  8. Developer and System Responsibilities Broken Abstract Model Repaired Abstract Model Abstract Repair Consistency Check 4 Consistency Constraints 5 2 Model Translation Model Definition Rules 3 1 6 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Automatically Generated Concrete Repair Broken Bits Repaired Bits

  9. Architecture Rationale Why use the abstract model? • Model construction separates objects into sets • Reachability properties • Field values • Different constraints for objects in different sets • Appropriate division of complexity • Data structure representation complexity encapsulated in model definition rules • Consistency property complexity encapsulated in (clean, uniform) model constraints

  10. Talk Outline • File System Example • Model Definition Rules • Consistency Constraints • Abstract Repairs • Concrete Repairs • Benchmarks • Related Work • Conclusion

  11. 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]; }

  12. 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

  13. 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

  14. 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

  15. Developer and System Responsibilities Broken Abstract Model Repaired Abstract Model Abstract Repair Consistency Check 4 Consistency Constraints 5 2 Model Translation Model Definition Rules 3 1 6 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Automatically Generated Concrete Repair Broken Bits Repaired Bits

  16. 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

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

  18. Developer and System Responsibilities Broken Abstract Model Repaired Abstract Model Abstract Repair Consistency Check 4 Consistency Constraints 5 2 Model Translation Model Definition Rules 3 1 6 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Automatically Generated Concrete Repair Broken Bits Repaired Bits

  19. 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

  20. 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

  21. 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

  22. Developer and System Responsibilities Broken Abstract Model Repaired Abstract Model Abstract Repair Consistency Check 4 Consistency Constraints 5 2 Model Translation Model Definition Rules 3 1 6 10111001011 10101011101 10101110110 00011001011 10101011101 10101110110 Automatically Generated Concrete Repair Broken Bits Repaired Bits

  23. 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.

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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

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

  32. 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

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

  34. 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

  35. 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

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

  37. 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

  38. 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)

  39. 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)

  40. 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)

  41. 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

  42. 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

  43. 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

  44. AbiWord Screen Shot

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

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

  47. 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

  48. 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

  49. CTAS Screen Shot

  50. 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

More Related