I did a bit of experimentation with practice mode, and the results seem to confirm that the contest backend doesn't suffer from the same deadlock as interactive_runner. I was able to get submissions to run successfully despite writing many gigabytes of junk to stderr.
The behavior seems to be consistent with stderr being simply redirected to /dev/null (although of course I don't know if that's what's actually happening). For what it's worth, I also can't reproduce the problem described in the beginning of this thread. My test runs with the given Java code were successful, regardless of whether the "err" variable was set to true or false. On Monday, May 20, 2019 at 9:45:59 AM UTC-5, Pablo Heiber wrote: > Hi, > > Thanks for this report (and to a few others who reported related > issues with interactive_runer.py privately). > > The interactive_runner does not run the same code as the judging that > happens on our backend. It's not even a stripped down version of it, > and it's not even using the same programming language, so any issues > with interactive_runner are completely independent of the judging > happening in the backend. > > We are looking into providing a more robust interactive_runner moving forward. > > When comparing times running in out backend, remember that: > 1. Test runs have a time limit of 10s, regardless of any time limits > in the problem you are testing. > 2. Writing to stderr does consume time and memory, and doing it a lot > in an interactive problem can consume a significant amount of time > because of additional context switching triggered by it, depending on > when the stderr is actually written (if you are letting your language > flush the buffer for you, it's possible that is doing it too often > and/or at an inconvenient time). > > Because of 1, getting a TLE error in a test run does not mean the > exact same code with the exact same input would get that when > submitting. In addition, the randomness for test runs (coming from the > code you provide, possibly the local testing tool) is different than > the randomness in the actual judge (different seed and randomness > algorithms, for security), which can also impact the behavior of the > program by affecting the "input". > > Best, > Pablo > > On Mon, May 20, 2019 at 6:33 AM Jacob Dlougach <[email protected]> wrote: > > > > суббота, 18 мая 2019 г., 13:25:34 UTC+3 пользователь Ricola написал: > > > So ... still no feedback on this? > > > For me it looks like the online judge is not respecting his own > > > specifications... > > > > My guess from using the interactive runner is that there is some limit on > > how much you can actually output in the stderr. The problem is that if > > stderr is connected to a pipe, and this pipe is only read after the > > solution has terminated, it's possible that the pipe will exhaust its > > buffer and hang on any attempt to write into it. > > > > If the same behavior is present in the online judge, I agree it needs to be > > fixed. If you don't get a response here, consider writing to > > [email protected] > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Code Jam" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To post to this group, send email to [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/google-code/d319e94e-4090-4f54-964c-4e69cea2b8f3%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Google Code Jam" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-code/17cd1202-0226-4370-b5d4-6ae123e6c70d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
