Allow adding callbacks to org.mozilla.javascript.Parser

[allvo]

The parser in Rhino 1.7.7.2 was looping forever on the following simple [incorrect] script: `hangsforever(function() {

)`.
Although the bug has been fixed in d30a8eb (if I'm not mistaken) and is not reproducible in 1.7.9, this rises the question of how to identify a situation where the parser has got into a similar loop.

I suggest adding callbacks functionality similar to what Rhino has for script execution (Context#observeInstructionCount and ContextFactory#observeInstructionCount) to the parser.

This may be useful not only in preventing endless looping, but also stopping parsing of a too heavy script.

If you are ok with this suggestion or have an alternative solution, I can implement it and submit a pull request.

[gbrail]

I'm all for making the code more robust, but does this make more sense than making sure that the parser can't get into an infinite loop? Are there legitimate situations in which one can create JavaScript syntax that causes a parser to fall into an infinite loop?

…

On Wed, May 9, 2018 at 3:04 AM allvo ***@***.***> wrote: The parser in Rhino 1.7.7.2 was looping forever on the following simple [incorrect] script: `hangsforever(function() { )`. Although the bug has been fixed in d30a8eb <d30a8eb> (if I'm not mistaken) and is not reproducible in 1.7.9, this rises the question of how to identify a situation where the parser has got into a similar loop. I suggest adding callbacks functionality similar to what Rhino has for script execution (Context#observeInstructionCount and ContextFactory#observeInstructionCount) to the parser. This may be useful not only in preventing endless looping, but also stopping parsing of a too heavy script. If you are ok with this suggestion or have an alternative solution, I can implement it and submit a pull request. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#435>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAf0a5XyEizGID8Vhwgmx5aedMbB6hCuks5twr8ygaJpZM4T4DMm> .

[morj]

@gbrail obviously not, but making sure the compiler doesn't go into real infinite loop without any instruction count or time limit would mean to solve the Halting problem

[allvo]

I'd want to add that having such callbacks not only helps to recover from potential parser issues. Let me share a usecase that will illustrate the need for such callbacks. I'm a member of a team developing a Java application that leverages Rhino to run arbitrary JS submitted by users. The above mentioned hooks allow us to make sure a script does not run too long. What we can not handle, however, is user's call to eval, which uses the same parser under the hood.