Comment 34 for bug 1066046

> Now lets think about the value of lr. It got set as 0x499fe5dc because of the "blx r8" that we followed earlier. Now almost immediately inside cti_op_resolve_global we call "bl", which will change the value of lr. However, lr does *not* reflect the return location for the "bl 0x41cf4aac" call. This means either:
> 1. We crashed before executing the bl inside cti_op_resolve_global (seems impossible), or
> 2. We executed the bl inside cti_op_resolve_global, and then restored lr, and returned. (seems likely)

This makes sense, and there is a third option. Actually the purpose of such stub code is allowing returning to anywhere in JIT, mainly used by exception handlers. So the return value is stored on the stack (like x86), can be changed (like a buffer overflow attack, but this is intentional here) so the c++ function can return anywhere, including a catch handler.

So we have two new options:
1) A wrong handler was set
2) Something overwrites the return value

Would be good to know if an exception occures just before the return...

Perhaps the following code also crashes:

try {
  var a = "a";
  a++;
} catch(e) { }