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,244 views

Published on

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

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,244
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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  

×