New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-15792] error: Segmentation fault: 11 on compile of project #58069
Comments
I don't think I can share the code – working on trying to make something minimized – but it looks like I'm running into the same (or nearby) issue with Xcode 13.3 beta (13E5086k). 3 libsystem_platform.dylib 0x000000019afe04e4 _sigtramp + 56
4 swift-frontend 0x0000000105896898 swift::rewriting::PropertyMap::concretizeNestedTypesFromConcreteParent(swift::rewriting::Term, swift::RequirementKind, swift::CanType, llvm::ArrayRef<swift::rewriting::Term>, llvm::ArrayRef<swift::ProtocolDecl const*>, llvm::TinyPtrVector<swift::ProtocolConformance*>&, llvm::SmallVectorImpl<std::__1::pair<swift::rewriting::MutableTerm, swift::rewriting::MutableTerm> >&) const + 1472
5 swift-frontend 0x0000000105896898 swift::rewriting::PropertyMap::concretizeNestedTypesFromConcreteParent(swift::rewriting::Term, swift::RequirementKind, swift::CanType, llvm::ArrayRef<swift::rewriting::Term>, llvm::ArrayRef<swift::ProtocolDecl const*>, llvm::TinyPtrVector<swift::ProtocolConformance*>&, llvm::SmallVectorImpl<std::__1::pair<swift::rewriting::MutableTerm, swift::rewriting::MutableTerm> >&) const + 1472
6 swift-frontend 0x0000000105896224 swift::rewriting::PropertyMap::concretizeNestedTypesFromConcreteParents(llvm::SmallVectorImpl<std::__1::pair<swift::rewriting::MutableTerm, swift::rewriting::MutableTerm> >&) const + 532
7 swift-frontend 0x0000000105894ba8 swift::rewriting::PropertyMap::buildPropertyMap(unsigned int, unsigned int) + 2652
8 swift-frontend 0x00000001058a3178 swift::rewriting::RequirementMachine::computeCompletion(swift::rewriting::RewriteSystem::ValidityPolicy) + 192
9 swift-frontend 0x00000001058a2fe0 swift::rewriting::RequirementMachine::initWithGenericSignature(swift::CanGenericSignature) + 892
10 swift-frontend 0x00000001058aa034 swift::rewriting::RewriteContext::getRequirementMachine(swift::CanGenericSignature) + 240 |
@swift-ci create |
Reduced: protocol Collection {
associatedtype SubSequence: Collection
}
protocol BidirectionalCollection: Collection where SubSequence: BidirectionalCollection {}
struct Slice<Base : Collection> : Collection {
typealias SubSequence = Slice<Base>
}
extension Slice: BidirectionalCollection where Base : BidirectionalCollection {}
protocol SlicedCollection: BidirectionalCollection where SubSequence == Slice<Self> {} |
Reduced the other problem: public protocol RealmCollection: RealmCollectionBase {}
public protocol RealmCollectionBase: RandomAccessCollection where Element: RealmCollectionValue {
}
public protocol RealmCollectionValue: _HasPersistedType where PersistedType: RealmCollectionValue {}
public protocol _HasPersistedType {
associatedtype PersistedType
}
public protocol PersistableEnum: _PersistableInsideOptional, _RealmCollectionValueInsideOptional {
}
public protocol _PersistableInsideOptional: _Persistable where PersistedType: _PersistableInsideOptional {}
public protocol _Persistable: _HasPersistedType where PersistedType: _Persistable {}
public protocol _RealmCollectionValueInsideOptional: RealmCollectionValue where PersistedType: _RealmCollectionValueInsideOptional {}
func foo<T>(_: T) where T : RealmCollection, T.Element : PersistableEnum {
_ = T.self
} |
@gregomni Can you file a separate bug for your crash since I don't think it's related to either of these two above? |
Fix for the first problem: #41255 The second problem appears because the recursion on the PersistedType associated type is too complex. On the main branch, this no longer triggers an internal assertion and instead emits a diagnostic on the PersistentEnum protocol. The core of the problem is that while we can support infinitely-recursive associated types with requirements, or merging two associated types with the same name from unrelated protocols, we cannot do both. Here is the simplest example showing the unsupported case – this example actually works in 5.6 but it's banned entirely on the main branch because we can't actually support it correctly with the current design: protocol P0 {
associatedtype PersistedType : P0
}
protocol P1 : P0 where PersistedType : P1 {}
protocol P2 : P0 where PersistedType : P2 {}
protocol P3 {
associatedtype X : P1 & P2
} Your project is the first one I've seen with a non-contrived example of this issue – congratulations 🙂 There are two solutions right now:
Please reach out if you need further help here, and I apologize for the source breaking change. |
Comment by Thomas Goyne (JIRA) Requiring a fixed point after two steps is probably fine. That's actually the intended design, and IIRC the problem with expressing that in the protocol was just that one of the older versions of Swift we support didn't like it. It's technically an API breaking change to add now, but it's very unlikely that anyone is intentionally depending on multiple steps and we're generally okay with shipping theoretically breaking changes tied directly to new Swift versions. |
Thank you for the response. I actually tried the change I suggested with Swift 5.5 and it seemed to work. Let me know if you run into any trouble. |
Do you mind if I resolve the bug since the fix for the first crasher has been merged into the release/5.6 branch? |
Comment by Thomas Goyne (JIRA) With Xcode 13.3 beta 3 the compiler still crashes rather than failing gracefully without the `PersistedType.PersistedType == PersistedType` requirement. `PersistedType.PersistedType == PersistedType` also doesn't actually work; the library builds but the tests don't. `PersistedType.PersistedType.PersistedType == PersistedType.PersistedType` appears to be the correct requirement. |
The compiler fails gracefully on the main branch once the `-requirement-machine-protocol-signatures=on` flag is enabled by default. I'll resolve this bug once that's in place. |
This is perhaps the same issue but the call stack is different... |
-requirement-machine-protocol-signatures=on is enabled in the 5.7 branch which means we will diagnose the unsolvable protocol rewrite system instead of crashing. |
Environment
macOS Monterey 12.2 (21D49)
Xcode Version 13.3 beta (13E5086k)
MacBook Pro (16-inch, 2019)
2.6 GHz 6-Core Intel Core i7
Additional Detail from JIRA
md5: 2f8ceba9b8ca620b92d0114165082661
is duplicated by:
Issue Description:
Since upgrading to Xcode Version 13.3 beta (13E5086k) we are seeing issues where compiling our project generates a "error: Segmentation fault: 11" / "error: Abort trap: 6". The project in question compiles with no issues on Xcode Version 13.2.1 (13C100).
Reproduction:
Crash 1:
Crash 2:
The text was updated successfully, but these errors were encountered: