OK, I’m still curious why the stack size is bigger when running via the test harness, but I agree with your conclusion. Here’s a PR to change the “REQUIRES” line to mention “deterministic-behavior”:
https://github.com/apple/swift/pull/6951 <https://github.com/apple/swift/pull/6951> > On Jan 19, 2017, at 8:16 PM, Slava Pestov <spes...@apple.com> wrote: > > I think this is fine. > > We have a bunch of compiler_crashers which are non-deterministic because they > trigger undefined behavior at runtime, such as dangling pointers, stack > overflow, etc. > > Disabling this is OK for now (it is still in compiler_crashers/ so it is > understood it is not yet fixed). In this case, the stack overflow won’t > really be addressed properly until we rework the parser to maintain its own > counter of nesting depth and bail out if its too deep. > > Alternatively we could up the number of { in the test until it crashes > reliably on all of our test machines… > > Slava > >> On Jan 19, 2017, at 6:38 PM, Bob Wilson via swift-dev <swift-dev@swift.org> >> wrote: >> >> As part of the move to reset the Clang/LLVM stable branches to their new >> versions, I disabled the >> compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift >> test because it was consistently failing to crash when I ran the tests >> locally. (It is expected to crash, so the test fails when it does not crash >> the compiler.) This is very strange because the test system prints out the >> failing command, and when I run that directly, I always get a crash. I can >> run it in a debugger and see that it is overflowing the stack. >> >> For some reason, when the test runs from the test harness, it does not >> crash. Of course I get a ton of diagnostics because the input is invalid, >> but there is no crash. I tried doubling the number of braces in the test, >> but that did not help. I also tried to increase my stack size in case the >> test harness does that, but ulimit had no effect. >> >> I don’t want to leave this test in limbo, but I’m kind of stuck figuring out >> why it is behaving inconsistently. Any ideas? >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
