[webkit-dev] Infinite JavaScript loop blocks the MiniBrowser

[Mark Lam]

Pascal,
I was wrong.  Please see https://bugs.webkit.org/show_bug.cgi?id=131082#c1 for details.

The gist of it is that the existing watchdog mechanism requires that the user of the VM explicitly reset it before any scripts are allowed to run again.  For example, you can do that by calling JSContextGroupSetExecutionTimeLimit() again.

Hence, you’re probably not resetting the watchdog after a time out.

Regards,
Mark


> On Jul 29, 2015, at 9:54 AM, Mark Lam <mark.lam at apple.com> wrote:
> 
> Pascal,
> 
> You can take a look at ExecutionTimeLimitTest.cpp for examples of the watchdog in action.  The way the watchdog works is by throwing a non-catchable TerminatedExecutionException.  Normally, the JSC APIs will clear the vm->exception() before returning to client code; the exception is returned to the caller via an argument.  Thereafter, you should be able to re-enter the VM and execute JS code like normal without needing to do any explicit resets.
> 
> If you’re not able to do this, then I suspect you have a code path where the termination exception is not cleared before re-entering the VM.  All the entry points in Interpreter.cpp already check for this with an "ASSERT(!vm.exception())”.  If you see that assertion fail on a debug build when re-entering the VM, then the bug is that the exception is not being cleared.  If you don’t see that assertion, then you’ll need to do some debugging to see what went wrong.
> 
> Another detail is that the Watchdog::Scope is responsible for disarming the watchdog when you exit the VM.  Watchdog::Scope is already being used in all the proper places.  Disarming in this case also means that the watchdog will be ready to start fresh when you enter the VM again.  If you have a bug in your disarming code where it’s not reseting the watchdog, then it is possible that your watchdog is firing immediately when you re-enter the VM.  Some tracing / debugging in your watchdog implementation should quickly show if that’s the case.
> 
> Regards,
> Mark
> 
> 
> 
>> On Jul 28, 2015, at 11:14 AM, Geoffrey Garen <ggaren at apple.com <mailto:ggaren at apple.com>> wrote:
>> 
>> Mark, do you know how to restart JavaScript after it has reached a watchdog time limit?
>> 
>> Geoff
>> 
>>> On Jul 28, 2015, at 9:09 AM, Pascal Jacquemart <p.jacquemart at samsung.com <mailto:p.jacquemart at samsung.com>> wrote:
>>> 
>>> Hello,
>>> 
>>> I am trying to protect the MiniBrowser from executing faulty JavaScript code taking too much time / CPU. All browsers normally raise a pop-up allowing the user to stop the script and run away. 
>>> But MiniBrowser does not seem to have such feature. It is just stuck forever ;-(
>>> 
>>> After a little digging I found this JSC API: JSContextGroupSetExecutionTimeLimit()
>>> I had to implement a JSC Watchdog back-end because it is not implemented for EFL, fair enough -> https://bugs.webkit.org/show_bug.cgi?id=147107 <https://bugs.webkit.org/show_bug.cgi?id=147107> (ongoing)
>>> 
>>> Now the JSContextGroupSetExecutionTimeLimit() have the expected behaviour.
>>> I can stop the JavaScript execution and run away... Great but the big problem now is that the JavaScript won't restart. Even while loading other pages, the JavaScript remains disabled.
>>> 
>>> If you have any hints about this, I would be grateful.
>>> How to restart JavaScript execution? Where to look? Is it an EFL bug?
>>> 
>>> Thanks,                       Pascal Jacquemart
>>> 
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150729/be205357/attachment.html>