[swift-dev] problem with compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift

[Slava Pestov]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev