The test relied on weird behaviour that PHP exceptions shouldn't stop
JavaScript code execution. Since JavaScript execution is now stopped,
the JavaScript catch handler is not executed anymore.
We don't know whether the V8Js object dtor or the script (resource)
dtor is called first. Nevertheless they depend on each other as
we must not simply Reset the persistent v8::Script if the v8::Isolate
was disposed before.
Now the V8Js dtor iterates over all script resources and resets the
persistent v8::Script instances; leaving an invalidated resource
object (which cannot be called anymore).
Without the compare function std::map simply compares one
pointer to another. However we need to compare the actual
strings.
Besides we must not efree normalised_module_id on return
of require method, since the pointer was added to
modules_loaded (and is valid until destruction of V8Js
class); instead it is now freed during V8Js object destruction.
Currently it just enables RSHUTDOWN code that should print
memory usage statistics. However the code implements API calls
that aren't supported anymore (for a long time).
The V8::TerminateExecution does *not* immediately terminate execution
as its name might suggest. It just marks the given isolate as
"to terminate" and the execution thread checks - from time to time -
whether to terminate. For v8 itself this is not problematic as
the call is thought to stop long-running scripts executed in the
browser context.
As v8js exposes this function to JavaScript with the exit() method,
this behaviour is confusing. In order to stop code execution right
at the exit() call, v8js enters an endless loop and waits for v8
to terminate execution within it.
Added a "%s" so both messages are matched:
* Extension or internal compilation error: MakeReferenceError in handlebars at line 1.
* Extension or internal compilation error in handlebars at line 1.
