102615607 gets stack overflow but runs fine locally. I'm generating input according to this comment (BledDest correct me if I'm wrong), and I'm using vm arguments -Xmx1024m -Xss64m
, as suggested by the memory limit and this blog. Just in case testcase 50 was generated differently, I also tried generating input using n = 1e8 which worked fine, albeit taking 150 seconds and requiring a lot more memory. So now I am somewhat confused: Why am I getting stack overflow?
Edit: Things take an interesting turn...
For the past ~6 months, I've always been setting the stack size to a large amount in order to avoid stack overflow javadoc. The behavior of the method had always been consistent, and it worked fine for a long time. However, the behavior changed during the last contest. 102588854 was fine, but 102610828 40 minutes later gave MLE on test 1. I changed the stack size from 1<<28
to 1<<27
, which fixed the problem for 102611202 and 102612993. However, 102615154 which was submitted only 5 minutes later gave an unexpected MLE on test 6, which is quite strange, considering it had previously worked fine for 5 tests.
Now it seems that 1<<27
is fine again 102660282. However, it gives a strange error message, leading me to suspect there's an issue with the grader. I then tried setting the stack size to 1<<29
, which gave an unsurprising MLE on test 1 102714946. What particularly interests me is that setting the stack size to 1<<29
works fine on custom invocation. In addition, 102660282 also works on custom invocation (once again, assuming that the testcase is generated according to BledDest's comment). I think this strange behavior calls for some investigation MikeMirzayanov? Although JavaDoc doesn't make any guarantees to the method, I think it should remain fairly consistent, especially during contests. In addition, custom invocation should produce the same results as the grader, since the whole point of it is to simulate the grader.