Closed jhudsy closed 3 years ago
This has been a recurring issue in my usage. However as it's a rare issue and usually quickly diagnosed I did not give it much thought. It arises from the need to communicate with the process. See 31447.
A workaround was used initially and consisted of redirecting IO to some file on the filesystem and re read them after completion. I avoided that since I did not want to hit the filesystem too many time (with the database already being hit a lot).
I'll be resolving this in the next major release. 2.1.x
One possible (hacky) fix would be to prepend a ulimit -m
The main problem with this would be for complied languages, but if the ulimit was inserted after the compilation stages, this could also be overcome.
This could also perhaps be used to limit buggy processes writing too much to the file system etc.
I'll try find some time to work through the code to try work out how easy/difficult this would be to do.
This is something I had not thought of. Although since ulimit
works based on CPU time, wouldn't timeout be a better thing to use? I say this because there's nothing preventing a person from introducing a sleep(1000) equivalent this the code and ulimit would not kill that whereas timeout would.
This is an ok way to go about it though, until the python timeout issue is not resolved.
That's a good point, but while it's sleep-ing, it wouldn't be doing any computation and would use minimal resources, so I don't think it's too bad. If timeout is fixed that would be better though.
https://github.com/theSage21/openJudge/pull/27 partially fixes this.
So I ran my first contest with openJudge today, which went relatively smoothly. However, one of the contestant's programs had a bug, namely an infinite loop. I had set the timeout in the config file (to 5 seconds), but that didn't seem to help (at least under python2) - the process ran and had to be killed manually, which eventually forced me to kill and restart openjudge for things to keep working properly (at least I think this was the problem; the testcase was also very large, around 40k lines). Nevertheless, I can recreate the problem with an infinite loop program, something like the following in Python.