Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ReCrash	             Making	  crashes	  reproducible	              by	  preserving	  object	  states	  Shay	  Artzi,	  Sun...
Eclipse	  bug	  30280:  	     2	  days	  to	  reproduce,	  4	  minutes	  to	  fix                                          ...
Reproducing	  crashes	  •  If	  a	  crash	  can’t	  be	  reproduced:	      –  Hard	  to	  fix	      –  Hard	  to	  validate...
Approach	  1:	  	  Postmortem	  analysis                                            	  Examples:	  	  stack	  trace,	  cor...
Approach	  2:	  	  Record	  &	  replay	  •  Logging:	  	  record	  interacYons	  with	  environment	  •  Replay:	  	  use	...
Record	  &	  replay	  for	  OO	  programs                                              	  •  Object-­‐oriented	  style	  u...
ReCrash	  technique	  Goal:	  	  Convert	  a	  crash	  into	  a	  set	  of	  unit	  tests	  1.  Monitoring:	  	  maintain	...
Maintaining	  the	  shadow	  stack	  •  On	  method	  entry:	     –  Push	  a	  new	  shadow	  stack	  frame	     –  Copy	...
Create	  one	  JUnit	  test	  per	  stack	  frame	  	                                               Test case for Eclipse ...
EvaluaYng	  unit	  tests	  •  Run	  each	  generated	  unit	  test	  •  Discard	  the	  test	  if	  it	  does	  not	  repr...
How	  a	  developer	  uses	  the	  tests	  •  In	  a	  debugger,	  step	  through	  execuYon	  and	     examine	  fields	  ...
Why	  create	  mulYple	  tests?	  •  Not	  all	  tests	  may	  reproduce	  the	  failure	      –  Due	  to	  state	  not	 ...
Not	  every	  test	  is	  useful	  Stack	  trace:	              Tests:	  NullPointerException           void test_toString...
Other	  features	  of	  ReCrash	  •  Non-­‐crashing	  failures	      –  Add	  a	  ReCrash	  annotaYon	  •  Caught	  excepY...
Cost	  of	  monitoring	  Key	  cost:	  	  copying	  arguments	  to	  shadow	  stack	  Tradeoff:	  	  less	  informaYon	  in...
Original	  program	  execuYon	  Real	  stack	  
Original	  program	  execuYon	   R:	                   17Real	  stack	  
Original	  program	  execuYon	   R:	                   17Real	  stack	  
Original	  program	  execuYon	   R:	                   18Real	  stack	  
Original	  program	  execuYon	   R:	   A1:	   R:	                   18Real	  stack	  
Original	  program	  execuYon	   R:	   A1:	   A2:	   R:	   A1:	   R:	                   18Real	  stack	  
1.	  	  Depth	  of	  copying	  
Deep	  copy	  Real	  stack	             Shadow	  stack	  
Deep	  copy	   R:	               17            R:	                 17Real	  stack	                  Shadow	  stack	  
Deep	  copy	   R:	               18            R:	                 17Real	  stack	                  Shadow	  stack	  
Deep	  copy	   R:	                             R:	   A1:	                            A1:	                                 ...
Deep	  copy	   R:	                             R:	                 18 A1:	                            A1:	   A2:	         ...
Deep	  copy	             Multiple copies ⇒ quadratic cost           Unusable in practice R:	                              ...
Reference	  copy	  Real	  stack	               Shadow	  stack	  
Reference	  copy	   R:	               17              R:	  Real	  stack	                    Shadow	  stack	  
Reference	  copy	   R:	               18              R:	  Real	  stack	                    Shadow	  stack	  
Reference	  copy	   R:	                               R:	   A1:	                              A1:	   R:	               18 ...
Reference	  copy	   R:	                               R:	   A1:	                              A1:	   A2:	                 ...
Depth-­‐1	  copy	   R:	                                R:	                 18 A1:	                               A1:	   A2...
2.	  	  Ignoring	  some	  fields                                  	  
Depth-­‐1	  copy	   R:	                                R:	                 18 A1:	                               A1:	   A2...
Used	  fields	                      Analysis results R:	                                        R:	                 18 A1:	...
Depth1	  +	  used	  fields	                      (=	  Depth2	  –	  unused	  fields)	   R:	                                  ...
Pure	  methods	                      Analysis results R:	                                    R:	                 18 A1:	  ...
Pure	  methods	   R:	                               R:	   A1:	                              A1:	   A2:	                   ...
Immutable	  objects	                      Analysis results R:	                                   R:	   A1:	               ...
Immutable	  objects	   R:	                             R:	   A1:	                            A1:	   A2:	                  ...
3.	  	  Ignoring	  some	  methods                                    	  
Ignored	  methods	                      Analysis results R:	                                    R:	   A1:	                ...
Ignored	  methods	   R:	                                R:	   A1:	                               A1:	   A2:	              ...
Methods	  that	  are	  unlikely	  to	  be	  useful                                                       	  •    Trivial	 ...
Second	  chance	  mode	  Idea:	  	  monitor	  only	  methods	  that	  are	  likely	  to	  crash	  •  IniYally,	  monitor	 ...
Experimental	  study	  1.    Can	  ReCrash	  reproduce	  failures?	  2.    Are	  the	  ReCrash-­‐generated	  tests	  usefu...
Subject	  programs                                          	  InvesYgated	  11	  real	  crashes	  from:	         –  BST:	...
Q1:	  	  Can	  ReCrash	  reproduce	  failures?	    Program	   Failure	                Candidate	         Reproducible	  te...
Q1:	  	  Can	  ReCrash	  reproduce	  failures?	    Program	   Failure	                Candidate	         Reproducible	  te...
Q2:	  	  Are	  the	  ReCrash	  tests	  useful?	  •  Developers	  found	  the	  tests	  useful	     –  Developer	  1:	  	  ...
Q3:	  	  How	  large	  are	  the	  test	  cases?	  •  The	  JUnit	  test	  suite	  uses	  the	  shadow	  stack	  •  Serial...
Q4:	  	  Time	  overhead	  of	  ReCrash	   SVNKit                                                          Original       ...
Q4:	  	  Memory	  overhead	  of	  ReCrash	  Absolute	  memory	  overhead:	  	  .2M	  –	  4.7	  M	  
GeneraYng	  unit	  tests	  from	  system	                      runs	  •  Test	  factoring	  [Saff	  2005,	  Elbaum	  2006]	...
Future	  work	  •  Capture	  more	  state	     –  Concurrency,	  Yming,	  external	  resources	  •  Other	  implementaYon	...
ReCrash	  converts	  failures	  into	  tests	  •  ReCrash	  effecYvely	  reproduces	  failures	      •  Replicates	  progra...
ReCrash	  converts	  failures	  into	  tests	  •  ReCrash	  effecYvely	  reproduces	  failures	      •  Replicates	  progra...
Maintaining	  the	  shadow	  stack	   R:	                             R:	   A1:	                            A1:	          ...
Maintaining	  the	  shadow	  stack	   On method entry R:	   A1:	   A2:	   R:	                             R:	   A1:	      ...
Maintaining	  the	  shadow	  stack	   On method entry: 1.  Push a new shadow stack frame R:	                              ...
Maintaining	  the	  shadow	  stack	   On method entry: 1.  Push a new shadow stack frame 2.  Copy the actual arguments to ...
Maintaining	  the	  shadow	  stack	   On method exit                                  R:	                 18              ...
Maintaining	  the	  shadow	  stack	   On method exit: 1.  Pop shadow stack frame R:	                             R:	   A1:...
Maintaining	  the	  shadow	  stack	   On program failure (top-level exception): R:	                                       ...
Maintaining	  the	  shadow	  stack	   On program failure (top-level exception): 1.  Write the shadow stack to a file R:	  ...
Maintaining	  the	  shadow	  stack	   On program failure (top-level exception): 1.  Write the shadow stack to a file      ...
ReCrash: Making crashes reproducible by preserving object states (ECOOP 2008)
ReCrash: Making crashes reproducible by preserving object states (ECOOP 2008)
Upcoming SlideShare
Loading in …5
×

ReCrash: Making crashes reproducible by preserving object states (ECOOP 2008)

1,482 views

Published on

It's really fun to work with Shay and Mike. Thank you!

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

ReCrash: Making crashes reproducible by preserving object states (ECOOP 2008)

  1. 1. ReCrash   Making  crashes  reproducible   by  preserving  object  states  Shay  Artzi,  Sunghun  Kim*,  Michael  D.  Ernst   MIT   * now at HKUST
  2. 2. Eclipse  bug  30280:   2  days  to  reproduce,  4  minutes  to  fix  2003-­‐01-­‐27    08:01   User:    Eclipse  crashed…    I  have  no  idea   why...    Here  is  the  stack  trace.  2003-­‐01-­‐27    08:26   Developer:    What  build  are  you  using?     Do  you  have  a  testcase  to  reproduce?  2003-­‐01-­‐27    08:39   Developer:    Which  JDK  are  you  using?  2003-­‐01-­‐28    13:06   User:    I’m  running  Eclipse  2.1,  …   I  was  not  able  to  reproduce  the  crash.  2003-­‐01-­‐29    04:33   Developer:    Reproduced.  2003-­‐01-­‐29    04:37   Developer:    Fixed.  
  3. 3. Reproducing  crashes  •  If  a  crash  can’t  be  reproduced:   –  Hard  to  fix   –  Hard  to  validate  a  soluYon  •  Reproducing  a  crash  is  hard!   –  Nondeterminism   –  ConfiguraYon  and  system  informaYon   –  Steps  to  reproduce  may  be  complex  or  long   –  In-­‐field  detecYon   –  Users  rarely  provide  reproducible  bug  reports  
  4. 4. Approach  1:    Postmortem  analysis  Examples:    stack  trace,  core  dump    Problems:  •  Fault  (bug)  may  be  far  from  failure  (excepYon)   –  Faulty  method  may  not  be  in  stack  trace  •  Too  much  informaYon   –  Core  dump:    big;  hard  to  interpret  •  Not  enough  informaYon   –  Shows  effects  (final  values),  not  causes   –  Need  iniYal  values  to  reproduce  the  failure  
  5. 5. Approach  2:    Record  &  replay  •  Logging:    record  interacYons  with  environment  •  Replay:    use  log  to  reproduce  the  execuYon  •  Checkpoint:    replay  skips  part  of  the  execuYon  Problems:  •  UnrealisYc  overhead  •  Invasive  changes  to  HW/OS/applicaYon  
  6. 6. Record  &  replay  for  OO  programs  •  Object-­‐oriented  style  uses  only  nearby  state   –  Unit  tesYng  depends  on  this  property  •  ReCrash  reproduces  this  nearby  state   –  Does  not  replay  an  execuYon   –  StaYc  and  dynamic  analyses  reduce  the  size  •  Lightweight:    efficient,  no  harness,  usable  in-­‐ field  •  Not  guaranteed  to  reproduce  every  failure  
  7. 7. ReCrash  technique  Goal:    Convert  a  crash  into  a  set  of  unit  tests  1.  Monitoring:    maintain  a  shadow  stack   –  Contains  a  copy  of  each  method  argument   –  On  program  crash,  write  the  shadow  stack  to  a  file  2.  Test  generaYon:    create  many  unit  tests   –  For  each  stack  frame,  create  one  unit  test:   •  Invoke  the  method  using  arguments  from  the  shadow   stack   •  If  the  test  does  not  reproduce  the  crash,  discard  the   test  
  8. 8. Maintaining  the  shadow  stack  •  On  method  entry:   –  Push  a  new  shadow  stack  frame   –  Copy  the  actual  arguments  to  the  shadow  stack  •  On  non-­‐excepYonal  method  exit:   –  Pop  the  shadow  stack  frame  •  On  program  failure  (top-­‐level  excepYon):   –  Write  the  shadow  stack  to  a  file   •  Serializes  all  state  referenced  by  the  shadow  stack  
  9. 9. Create  one  JUnit  test  per  stack  frame     Test case for Eclipse bug 30280  public void test_resolveType() { Read arguments from the saved shadow stack AllocExpr rec = (AllocExpr) shadowStack.getArg(0); BlockScope arg = (BlockScope) shadowStack.getArg(1); rec.resolveType(arg);} Invoke the method from the stack frame  We  expect  the  method  to  fail  as  it  did  at  run  Yme  
  10. 10. EvaluaYng  unit  tests  •  Run  each  generated  unit  test  •  Discard  the  test  if  it  does  not  reproduce  the   run-­‐Yme  excepYon  
  11. 11. How  a  developer  uses  the  tests  •  In  a  debugger,  step  through  execuYon  and   examine  fields  •  Experiment  by  modifying  the  tests  •  Verify  a  fix  •  Create  a  regression  test   –  Replace  deserialized  objects  by  real  objects  or   mock  objects   –  More  readable  and  robust  
  12. 12. Why  create  mulYple  tests?  •  Not  all  tests  may  reproduce  the  failure   –  Due  to  state  not  captured  on  the  shadow  stack   •  Sockets,  files,  nondeterminism,  distant  program  state   •  Does  capture  all  values  that  are  passed  as  arguments  •  Some  tests  may  not  be  useful  for  debugging  
  13. 13. Not  every  test  is  useful  Stack  trace:   Tests:  NullPointerException void test_toString() { at Class1.toString Class1 receiver = null; at Class2.myMethod receiver.toString(); ... } void test_myMethod() { Class2 receiver = (Class2) shadowStack.getArg(0); receiver.myMethod(); }
  14. 14. Other  features  of  ReCrash  •  Non-­‐crashing  failures   –  Add  a  ReCrash  annotaYon  •  Caught  excepYons  that  lead  to  later  failures  •  Adding  extra  informaYon  to  test  cases   –  Version  number,  configuraYon  informaYon  •  Reducing  the  serialized  stack   –  Size,  privacy  
  15. 15. Cost  of  monitoring  Key  cost:    copying  arguments  to  shadow  stack  Tradeoff:    less  informaYon  in  shadow  stack  ⇒   lower  chance  of  reproducing  failures  1.  Depth  of  copy   –  Deep,  reference,  or  a  hybrid  2.  Save  less  informaYon  about  each  argument   –  Focus  on  important  fields  3.  Monitor  fewer  methods   –  Ignore  methods  not  likely  to  crash  or  to  be  useful  
  16. 16. Original  program  execuYon  Real  stack  
  17. 17. Original  program  execuYon   R:   17Real  stack  
  18. 18. Original  program  execuYon   R:   17Real  stack  
  19. 19. Original  program  execuYon   R:   18Real  stack  
  20. 20. Original  program  execuYon   R:   A1:   R:   18Real  stack  
  21. 21. Original  program  execuYon   R:   A1:   A2:   R:   A1:   R:   18Real  stack  
  22. 22. 1.    Depth  of  copying  
  23. 23. Deep  copy  Real  stack   Shadow  stack  
  24. 24. Deep  copy   R:   17 R:   17Real  stack   Shadow  stack  
  25. 25. Deep  copy   R:   18 R:   17Real  stack   Shadow  stack  
  26. 26. Deep  copy   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  27. 27. Deep  copy   R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  28. 28. Deep  copy   Multiple copies ⇒ quadratic cost Unusable in practice R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  29. 29. Reference  copy  Real  stack   Shadow  stack  
  30. 30. Reference  copy   R:   17 R:  Real  stack   Shadow  stack  
  31. 31. Reference  copy   R:   18 R:  Real  stack   Shadow  stack  
  32. 32. Reference  copy   R:   R:   A1:   A1:   R:   18 R:  Real  stack   Shadow  stack  
  33. 33. Reference  copy   R:   R:   A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   R:   18 R:  Real  stack   Shadow  stack  
  34. 34. Depth-­‐1  copy   R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  35. 35. 2.    Ignoring  some  fields  
  36. 36. Depth-­‐1  copy   R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  37. 37. Used  fields   Analysis results R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  38. 38. Depth1  +  used  fields   (=  Depth2  –  unused  fields)   R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  39. 39. Pure  methods   Analysis results R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  40. 40. Pure  methods   R:   R:   A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  41. 41. Immutable  objects   Analysis results R:   R:   A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  42. 42. Immutable  objects   R:   R:   A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  43. 43. 3.    Ignoring  some  methods  
  44. 44. Ignored  methods   Analysis results R:   R:   A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  45. 45. Ignored  methods   R:   R:   A1:   A1:   A2:   A2:   R:   A1:   R:   18 R:   17Real  stack   Shadow  stack  
  46. 46. Methods  that  are  unlikely  to  be  useful  •  Trivial  methods  •  Private  methods  •  Library  methods  •  Methods  that  are  unlikely  to  crash  
  47. 47. Second  chance  mode  Idea:    monitor  only  methods  that  are  likely  to  crash  •  IniYally,  monitor  no  methods  •  Aner  a  crash,  add  monitoring  for  methods  in  the   stack  trace   –  Can  update  all  clients,  not  just  the  one  that  crashed  •  Tradeoffs:   +  Very  low  overhead  (no  overhead  unYl  a  crash)   –  Requires  a  failure  to  occur  twice  
  48. 48. Experimental  study  1.  Can  ReCrash  reproduce  failures?  2.  Are  the  ReCrash-­‐generated  tests  useful?  3.  How  large  are  the  test  cases?  4.  What  is  the  overhead  of  running  ReCrash?  
  49. 49. Subject  programs  InvesYgated  11  real  crashes  from:   –  BST:    .2  KLOC   –  SVNKit:    22  KLOC   –  Eclipse  compiler:    83  KLOC   –  Javac-­‐jsr308:    86  KLOC    
  50. 50. Q1:    Can  ReCrash  reproduce  failures?   Program   Failure   Candidate   Reproducible  tests   tests   reference   depth  1  +   deep   copy   used-­‐fields   copy   BST   Class  cast   3   3   3   3   Class  cast   3   3   3   3   Unsupported   3   3   3   3   SVNKit   Index  bounds   3   3   3   3   Null  pointer   2   2   2   2   Null  pointer   2   2   2   2   Eclipsec   Null  pointer   13   0   1   8   Javac-­‐ Null  pointer   17   5   5   5   jsr308   Illegal  arg   23   11   11   11   Null  pointer   8   1   1   1   Index  bounds   28   11   11   11  
  51. 51. Q1:    Can  ReCrash  reproduce  failures?   Program   Failure   Candidate   Reproducible  tests   tests   reference   depth  1  +   deep   copy   used-­‐fields   copy   BST   Class  cast   3   3   3   3   Class  cast   3   3   3   3   Unsupported   3   3   3   3   SVNKit   Index  bounds   3   3   3   3   Null  pointer   2   2   2   2   Null  pointer   2   2   2   2   Eclipsec   Null  pointer   13   0   1   8   Javac-­‐ Null  pointer   17   5   5   5   jsr308   Illegal  arg   23   11   11   11   Null  pointer   8   1   1   1   Index  bounds   28   11   11   11  
  52. 52. Q2:    Are  the  ReCrash  tests  useful?  •  Developers  found  the  tests  useful   –  Developer  1:    “You  don’t  have  to  wait  for  the   crash  to  occur  again”;  also  liked  mulYple  tests   –  Developer  2:    “Using  ReCrash,  I  was  able  to  jump   (almost  directly)  to  the  necessary  breakpoint”  •   Developers  found  the  stack  trace  insufficient   –  Unable  to  reproduce   –  The  failure  may  be  far  removed  from  the  fault  
  53. 53. Q3:    How  large  are  the  test  cases?  •  The  JUnit  test  suite  uses  the  shadow  stack  •  Serializes  all  reachable  parts  of  the  heap   Program   Average   shadow  stack   size  (KB)   BST   12   SVNKit   34   Eclipsec   62   Javac-­‐jsr308   422  
  54. 54. Q4:    Time  overhead  of  ReCrash   SVNKit Original Reference Depth  1  +  used-­‐fieldsEclipsec Second  chance 0 0.5 1 1.5 2Overhead  of  instrumented  program  in  the  field  
  55. 55. Q4:    Memory  overhead  of  ReCrash  Absolute  memory  overhead:    .2M  –  4.7  M  
  56. 56. GeneraYng  unit  tests  from  system   runs  •  Test  factoring  [Saff  2005,  Elbaum  2006]   –  Developer  selects  a  porYon  of  the  program   –  System  logs  interacYons  with  the  environment   –  Unit  test  replays  execuYon  in  a  test  harness  •  Contract-­‐driven  development  [Leitner  2007]   –  Reference  copying,  intended  for  durable  tests  •  Backward-­‐in-­‐Yme  debuggers  [Lienhard  2008]   –  Heavier-­‐weight  logging  and  checkpoints  
  57. 57. Future  work  •  Capture  more  state   –  Concurrency,  Yming,  external  resources  •  Other  implementaYon  tradeoffs   –  Copy-­‐on-­‐write   –  ExisYng  VM  hooks   –  Logging/debugging  techniques   –  These  are  probably  orthogonal  to  ReCrash  
  58. 58. ReCrash  converts  failures  into  tests  •  ReCrash  effecYvely  reproduces  failures   •  Replicates  program  states   •  Generates  mulYple  unit  tests  •  The  unit  tests  are  useful  •  Low  overhead   •  Records  only  relevant  parts  of  an  execuYon   •  4  program  analyses;  second  chance  mode   •  Can  deploy  instrumented  programs  in  the  field  •  Download:    hup://pag.csail.mit.edu/ReCrash/      
  59. 59. ReCrash  converts  failures  into  tests  •  ReCrash  effecYvely  reproduces  failures   •  Replicates  program  states   •  Generates  mulYple  unit  tests  •  The  unit  tests  are  useful  •  Low  overhead   •  Records  only  relevant  parts  of  an  execuYon   •  4  program  analyses;  second  chance  mode   •  Can  deploy  instrumented  programs  in  the  field  •  Download:    hup://pag.csail.mit.edu/ReCrash/      
  60. 60. Maintaining  the  shadow  stack   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  61. 61. Maintaining  the  shadow  stack   On method entry R:   A1:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  62. 62. Maintaining  the  shadow  stack   On method entry: 1.  Push a new shadow stack frame R:   R:   A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  63. 63. Maintaining  the  shadow  stack   On method entry: 1.  Push a new shadow stack frame 2.  Copy the actual arguments to the shadow stack R:   R:   18 A1:   A1:   A2:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  64. 64. Maintaining  the  shadow  stack   On method exit R:   18 A1:   A2:   R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  65. 65. Maintaining  the  shadow  stack   On method exit: 1.  Pop shadow stack frame R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  66. 66. Maintaining  the  shadow  stack   On program failure (top-level exception): R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  67. 67. Maintaining  the  shadow  stack   On program failure (top-level exception): 1.  Write the shadow stack to a file R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  
  68. 68. Maintaining  the  shadow  stack   On program failure (top-level exception): 1.  Write the shadow stack to a file Serializes all referenced state R:   R:   A1:   A1:   18 R:   18 R:   17Real  stack   Shadow  stack  

×