Can't terminate problem rendering during infinite loop

[Alex-Jordan]

With the problem editor, if I render a problem and I've entered an infinite loop, it seems that I must either sit though the timeout period or reload the page. Could there be a way to interrupt?

[drgrice1]

This can be done. Pull request coming shortly.

It isn't hard to cancel the iframe load and remove the loading overlay. However, there isn't much that can be done about your server still chugging away processing the request. So you should probably check your server's status and you might need to restart apache2 to properly clear out the job.

You are actually highlighting a more serious PG problem. Authors of PG problems can cause infinite loops that can basically render the server unresponsive for a period. PG needs better protections against this sort of thing.

[drgrice1]

By the way this is a webwork2 issue as you have phrased it for the pg problem editor. However, the real underlying issue of protecting against this sort of thing is a pg issue.

[taniwallach]

The current protection is the timeout, which seems to be set up and run by webwork2/lib/WeBWorK/PG/Local.pm. Although it does not seem perfect, it does seem to usually manage to kill problems with infinite loops or just excessively long loops of various sorts. However, I have experiences instances where it seem to have failed to kill an Apache process handling a question with a runaway loop.

When it works it triggers the message Timeout after processing this problem for ". TIMEOUT. " seconds. Check for infinite loops in problem source.\n";

From my experience the default value of TIMEOUT is 60 seconds which is set in webwork2/lib/WeBWorK/Constants.pm. I'm not aware of any convenient method to change the value other than modifying webwork2/lib/WeBWorK/Constants.pm.

I suspect that with the transition to WeBWorK 3 the Mojalicious code would be the place to put in place something to limit the time allowed for a problem to render. I do suspect that if the limit is lowered greatly, there may be a need to consider allowing specific problems to request large rendering times, or they may require major changes.

Quite a few OPL problems I have encountered use the approach of generating complicated parameter sets for problems in a loop which tests at the end for "validity" by some conditions. Typically those loops do not employ a loop counter and a fallback set of values if the loop hits the limit. A bad seed or bad approach can lead to some pretty bad cases.

[pstaabp]

I think we implemented the cancel on the old PGProblemEditor. Perhaps we should bring a cancel button back to the new one (currently in develop).

[drgrice1]

I don't really think that it is needed with the new design. It certainly isn't essential. With the old design when you rendered a problem a layover covered the entire page, making the page inoperable. So the escape action was necessary to allow the author to continue working without having to wait for the time out. With the new design that doesn't happen, and the page continues to be operable while the problem is loading.

[pstaabp]

Good point. Will close this issue.