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
