)]}'
{
  "log": [
    {
      "commit": "d45a1f5d1dd5bc9badfab3a8aee90c934d9f2227",
      "tree": "c4e92844452b5eabfbd936b8d83c54f58397475d",
      "parents": [
        "0adc680c388913a63666797e907f87c4c6b0b4ea"
      ],
      "author": {
        "name": "Sebastien Hertz",
        "email": "shertz@google.com",
        "time": "Thu Jan 09 14:56:54 2014 +0100"
      },
      "committer": {
        "name": "Sebastien Hertz",
        "email": "shertz@google.com",
        "time": "Fri Jan 10 09:42:09 2014 +0100"
      },
      "message": "Avoid instrumentation stack corruption.\n\nWhile debugging a throwing exception, we may end up updating instrumentation\nstack frame after having already walked the native stack. This leads to not pop\ninstrumentation frames prior to catch handler (or upcall if exception is not\ncaught) and get it desynchronized with the native stack.\n\nTo solve this issue, we need to walk the stack again after having reporting the\nexception to the instrumentation listener (for example: the debugger) which\nmay push new instrumentation stack frames. However we do it only when we know\ninstrumentation is enabled to not slow down exception delivery when executing\ncode without instrumentation.\n\nHere are the main changes:\n- Creates InstrumentationStackVisitor to compute the number of instrumentation\nframes to pop (previously done in CatchBlockStackVisitor). We only count frames\nprior to catch handler (or upcall). Popping instrumentation frames is done\nafter having reported the exception to the instrumentation listener.\n- Updates the CatchBlockStackVisitor to remove instrumentation frame handling\nand focus only on finding the catch handler and prepare deoptimization.\n- Creates CatchFinder class to control both visitors and do the long jump.\n\nChange-Id: I29b3871403f297bfb8c087e27f1330b002f5d56d\n"
    }
  ]
}