Défaut de segmentation du compilateur Swift lors de la construction

L'ajout d'une heightpropriété calculée (pratique) UIViewdans mon UIViewExtension.swiftfichier provoque le segfault du compilateur Swift ... Qu'est-ce qui pourrait ne pas se passer ici?

0  swift                    0x00000001061e5608 llvm::sys::PrintStackTrace(__sFILE*) + 40
1  swift                    0x00000001061e5af4 SignalHandler(int) + 452
2  libsystem_platform.dylib 0x00007fff894da5aa _sigtramp + 26
3  libsystem_platform.dylib 0xb03939841e997c88 _sigtramp + 2504775416
4  swift                    0x00000001064c8bb9 swift::NominalTypeDecl::getMembers(bool) const + 41
5  swift                    0x00000001055efab9 swift::irgen::ClassMetadataLayout<(anonymous namespace)::FindClassMethodIndex>::addClassMembers(swift::ClassDecl*) + 329
6  swift                    0x00000001055e97b2 swift::irgen::emitVirtualMethodValue(swift::irgen::IRGenFunction&, llvm::Value*, swift::SILType, swift::SILDeclRef, swift::CanTypeWrapper<swift::SILFunctionType>, swift::ResilienceExpansion) + 434
7  swift                    0x00000001056550d3 swift::SILVisitor<(anonymous namespace)::IRGenSILFunction, void>::visit(swift::ValueBase*) + 42611
8  swift                    0x000000010564a266 swift::irgen::IRGenModule::emitSILFunction(swift::SILFunction*) + 8678
9  swift                    0x00000001055cb6f8 swift::irgen::IRGenModule::emitGlobalTopLevel() + 184
10 swift                    0x00000001056376e3 performIRGeneration(swift::IRGenOptions&, swift::Module*, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, swift::SourceFile*, unsigned int) + 1859
11 swift                    0x0000000105638033 swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, unsigned int) + 51
12 swift                    0x00000001055aa65a frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 4842
13 swift                    0x00000001055a935d main + 1533
14 libdyld.dylib            0x00007fff8a82e5fd start + 1

1.  While emitting IR SIL function @_TFCSo6UIViewg6heightSd for 'anonname=0x7ff422892fd0' at <path redacted>/UIViewExtension.swift:60:5
<unknown>:0: error: unable to execute command: Segmentation fault: 11
<unknown>:0: error: swift frontend command failed due to signal (use -v to see invocation)
Command /Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift failed with exit code 254

Si plus d'informations sont nécessaires pour résoudre ce problème, il suffit de commenter. Merci!

Éditer:

Voici un .xcodeproj associé qui renvoie l'erreur de compilation de cette question. Télécharger ici

J'ai eu cette erreur parce que je faisais ceci:

if(currentMeal?.State == .Deleted){

}

au lieu de

if(currentMeal!.State == .Deleted){

}

donc je pense que facultatif non déballé si la condition peut provoquer cette erreur

Lorsque vous rencontrez un segfault de compilateur dans Swift, vous n'obtenez pas de numéro de ligne pratique et de message d'erreur. Voici comment vous pouvez localiser le problème:

1. Créez un nouveau fichier appelé SegFaultDebugger.swift dans votre projet.
2. Dans ce nouveau fichier, définissez une extension de la classe qui vous pose des problèmes.
3. Déplacer un groupe de méthodes du fichier principal vers SegFaultDebugger.swift .
4. Compiler.

À ce stade, l'une des trois choses suivantes se produit:

• Vous obtenez toujours le segfault dans le fichier d'origine : déplacez les méthodes de l' SegFaultDebugger.swiftarrière vers le fichier d'origine et déplacez un autre ensemble de méthodes dans SegFaultDebugger.swift. Répéter
• Vous obtenez un segfault dansSegFaultDebugger.swift : Super! Maintenant, utilisez la recherche binaire pour épingler le segfault à une méthode spécifique jusqu'à ce que vous puissiez comprendre quelle construction en est la cause.
• Vous obtenez des erreurs de compilation significatives : génial! Corrigez les erreurs. Une fois que tout est compilé, replacez vos méthodes dans le fichier d'origine.

J'ai eu cette erreur en étendant l'un de mes protocoles et en argument de type incorrect et facultatif.

protocol SomeProtocolName: class {
    var someProtocolVariable: String { get set }

    func someProtocolFunction(someProtocolVariable: String)
}

// MARK:
extension SomeProtocolName {
    func someProtocolFunction(someProtocolVariable: String?) {
        self.someProtocolVariable = someProtocolVariable
    }
}

La différence dans les arguments de fonction Stringdans le prototype et String?dans l'extension a causé l' erreur de segmentation 11 .

J'ai eu cette erreur aussi, et je l'ai corrigée comme ceci:

Vérifiez votre projet et découvrez quels fichiers sont utilisés deux fois et supprimez-en un, ou supprimez-les et rajoutez-les tous.

Erreurs dans mon Xcode:

: 0: erreur: nom de fichier "AttributedString.swift" utilisé deux fois: '/Users/.../CNJOB/CNJOB/AttributedString.swift' et '/Users/.../CNJOB/CNJOB/AttributedString.swift'

: 0: note: les noms de fichiers sont utilisés pour distinguer les déclarations privées du même nom

: 0: erreur: nom de fichier "APIClient.swift" utilisé deux fois: '/Users/.../CNJOB/CNJOB/APIClient.swift' et '/Users/.../CNJOB/CNJOB/APIClient.swift'

: 0: note: les noms de fichiers sont utilisés pour distinguer les déclarations privées du même nom

Commande / Applications / Xcode 3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc a échoué avec le code de sortie 1

Dans Xcode 7, vous pouvez cliquer sur l'erreur dans le navigateur de débogage et vous verrez une vue étendue des plantages. En cliquant sur le bouton hamburger à droite, l'erreur augmente, et si vous faites défiler jusqu'au bas du message d'erreur développé, vous verrez d'où il vient.

Pour moi, j'ai eu deux de ces erreurs de segmentation. Dans l'image ci-dessus, le premier est à quoi il ressemble lorsqu'il est réduit, le second est lorsque vous développez le bouton hamburger. Tout en bas de la zone grise développée, vous verrez un message indiquant où le compilateur s'est écrasé.

Notez cependant que le message d'erreur peut parfois ne pas être suffisamment informatif, donc s'il vous indique où il s'est écrasé, il ne dit pas toujours pourquoi et comment le réparer. Se débarrasser de cette erreur est toujours une question de conjectures.

J'ai découvert une solution de contournement simple jusqu'à ce que le problème soit résolu dans une future version Xcode / Swift:

• Placez simplement toutes les extensions à l'origine du problème dans le .swiftfichier utilisé.

Dans l'exemple de projet que vous avez fourni, placez le contenu de UIViewExtension.swift et au - CALayerExtension.swift dessus AppDelegate.swift

J'espère que cela nous permettra d'écrire du code Swift fonctionnel jusqu'à ce que le problème soit résolu.

Quant à moi, en ajoutant privateà statique var fixed clang crash:

private static var taskId = 0

J'ai eu une erreur de segmentation du compilateur sur une instruction comme celle-ci:

someFunction(isFlagged ? "String1" : "String2")

Je viens de faire une instruction if-else à la place et cela fonctionne.

Vous pouvez également avoir ce problème si vous déclarez une condition avec un Bool non emballé comme propriété

Dans mon cas, un deux-points mal placé lors de l'interpolation de chaîne a cassé le mien (XCode 6.1.1).

Exemple:

println("\(value1:value2)") 

quand je voulais faire:

println("\(value1) : \(value2)")

Cette erreur m'est arrivée lorsque j'ai essayé de remplacer la variable faible de la classe parent.

En classe de base:

weak var stripeViewDelegate : StripeViewDelegate? = nil    

Classe dérivée:

override weak var stripeViewDelegate : StripeViewDelegate? = nil {
    didSet {
        self.stripeView.delegate = stripeViewDelegate

    }

L'erreur a disparu lorsque j'ai supprimé =nilde la classe dérivée.

J'attrape une exception aujourd'hui

class func createByAny(instance: Any?) -> ApiCollectionResponse { ... }

et cela l'a résolu:

class func createByAny(instance: Any) -> ApiCollectionResponse { ... }

Parce que "Any" type est n'importe quel type event "nil", "AnyObject", optionnel, ... :) Il ne peut pas être optionnel, il est déjà optionnel.

typealias Any = protocol<>

Cette erreur se produit également si vous déclarez accidentellement une variable avec un type correspondant à son nom:

    var sectionGroup: sectionGroup? { ... }

Ran dans cette erreur en raison d'un type générique étranger sur une fonction d'opérateur, par exemple

func ==<T>(lhs: Foo, rhs: Foo) -> Bool {
  return lhs.bar == rhs.bar
}

Dans mon cas, la suppression a <T>résolu le problème.

Dans mon cas, j'avais déclaré un structintérieur a func. Déplacer lestruct au niveau de la classe a résolu le problème.

Maintenant que j'écris ceci, je me souviens avoir eu des problèmes avec l' structintérieur des funcs avant. C'était autre chose que la faute de segmentation (qui semble devenir notoire avec la version bêta de Swift 1.2). OMG Apple, qu'est-ce que tu fais là?

Dans mon cas, cette erreur car j'utilise le nom de classe pour la variable

var MYClass : MYClass {
    get {
        return.....
    }
}

Et cela résout mon problème

var myClass : MYClass {
    get {
        return.....
    }
}

Im mon cas, cela s'est produit lorsque j'ai fait une initialisation statique incorrecte dans un protocole. J'ai trouvé un moyen de me déplacer, mais un compilateur ne devrait jamais produire une erreur de segmentation lors de la construction.

Il y a trois fichiers impliqués. Un protocole NamedSegues.swift, un TableViewController personnalisé qui implémente entre autres le protocole qui contient un rappel, un TableViewCell personnalisé qui contient une référence à ce protocole pour appeler le rappel.

//file1
import Foundation
protocol NamedSegues {
    func  executeSegueWithId(id: String) -> Void
    static func getDefault() -> NamedSegues  // This was required because of init requirement in CustomCellView
}


//file2
class CustomController: UITableViewController, NamedSegues {
override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
            let cell = tableView.dequeueReusableCellWithIdentifier("CustomCellID", forIndexPath: indexPath ) as! CustomCellView

        // Configure the cell...
       //App logic...

        cell.parent = self
}

 //Mark: NamedSegues
     func executeSegueWithId(id: String) ->() {
        NSLog("Received callback to execute segue: \(id)")
        //
    }

    static func getDefault() -> NamedSegues { // I think this must be where it threw up.
        return self as! NamedSegues
    }

}


//file3

import UIKit

class CustomCellView: UITableViewCell {

    var id: String = "NoName"
    var parent: NamedSegues = NamedSegues.getDefault() // This is where it was needed.


override func touchesBegan(touches: Set<NSObject>, withEvent event: UIEvent) {
        NSLog("Touched id: \(id)")


             parent.executeSegueWithId(id) // This is where parent was used.
     }
}

Je l'ai contourné en utilisant?

Dans le fichier de protocole, file1: supprimez la déclaration de getDefault () Dans le fichier CustomController2: supprimez l'implémentation de getDefault. Dans CustomCellView, fichier3:

    var parent: NamedSegues?
    ...
    parent?.executeSegueWithId(id)

Le compilateur aurait dû intercepter cela et donner un message d'erreur au lieu de lancer une erreur de segmentation pendant la construction!

On dirait que le compilateur Swift 2 n'était peut-être pas tout à fait prêt pour les heures de grande écoute! Au cas où cela aiderait quelqu'un, j'obtenais une erreur de segmentation: 11 en raison d'une incompatibilité avec le type de variable dans un en-tête de fermeture, en particulier dans une méthode Parse,PFQuery.query.findObjectsInBackgroundWithBlock .

Vous pouvez voir le problème plus en détail ici: https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/280

Comme @Fjohn l'a dit, c'était un problème lié au déballage d'une option pour moi (cassé à la fois dans Xcode 7.0 beta 6 et Xcode 7). Dans mon cas, je n'étais pas en train de déballer l'option optionnelle de l'option (ce qui m'a averti était le double ?? dans le descripteur. Utiliser if let a résolu le problème

Comme d'autres l'ont écrit ci-dessus, pour moi, cela s'est produit lorsque j'utilise une extension sur un protocole mais que la signature des méthodes dans le protocole ne correspond pas aux implémentations d'une extension.

Dans mon cas, j'avais ajouté un nouveau paramètre à l'implémentation (dans l'extension) mais j'avais oublié de l'ajouter également à la signature de la méthode dans le protocole.

dans mon cas, j'ai essayé d'ajouter un paramètre de fonction après un paramètre variadique.

L'inversion de la séquence des paramètres et le fait de faire du paramètre variadique le dernier paramètre de la liste de paramètres l'ont corrigé.

Cela se produit généralement lorsque le compilateur n'a pas suffisamment d'informations (malgré ce que vous pensez) pour garantir / déterminer l'état d'une instruction ou d'une variable dans une instruction.

Par exemple, imaginez que vous avez un dictionnaire de type [String: String] que vous remplissez avec des noms de villes comme clés et une liste séparée par des virgules des codes postaux / codes postaux correspondants.

Imaginez que quelque part dans votre code, vous souhaitez mettre à jour la liste des codes correspondants:

myDict[town] += newZipCode + ","

Dans ce cas, le compilateur répondra avec une erreur de segmentation comme cela townpourrait ne pas être dans le dictionnaire et par conséquent, il ne peut pas garantir que l'instruction ci-dessus aura une valeur valide.

Pour résoudre ce problème, vous devez stocker l'état actuel de myDict[town]dans une variable distincte vous permettant de gérer la casse key not in dict, puis de mettre à jour la valeur de la clé donnée:

myDict[town] = guaranteedValue + "," newZipCode + ","

Malheureusement, il n'est pas toujours simple de déterminer la cause première, j'espère donc que cet exemple simple vous aidera.

Swift 3.0 (Xcode 8.1) présente ce problème lorsqu'un protocole déclare une variable facultative et qu'un implémenteur implémente cette variable comme une variable initialisée paresseusement.

Le bogue est signalé ici: https://bugs.swift.org/browse/SR-1825

Xcode 8.2.

Ajout de l' @nonobjcimplémentation du protocole dans l'extension provoquant des erreurs de segmentation. Déplacer l' @nonobjcimplémentation du protocole dans l'implémentation de classe.

Dans mon cas, le coupable surchargeait accidentellement une fonction s'attendant à un argument de tableau avec un avec un argument variadique :

public required init(_ args: Node...) {
}

Quand la superclasse l'avait défini comme un tableau:

public required init(_ args: [Node]) {
}

Pour moi, ce qui suit a causé un segfault alors que typec'est facultatif:

switch type {
    case .aType:
        // Do Something
    default:
        break
}

et cela l'a résolu:

switch type {
    case .Some(.aType):
        // Do Something
    default:
        break
}

J'ai eu cette erreur avec la signature de méthode suivante dans un UITableViewController personnalisé.

func filterContentForSearchText(searchText: String)

changer en:

func filterContentForSearchText(searchText: String!)

résolu le problème.

J'ai eu le même problème dans une extension. Mon extension avait deux initialiseurs pratiques:

convenience init(context: NSManagedObjectContext) {
    let entityDescription = NSEntityDescription.entityForName("PropertyEntity", inManagedObjectContext: context)!
    self.init(entity: entityDescription, insertIntoManagedObjectContext: context)
}

convenience init(dictionary: NSDictionary, context: NSManagedObjectContext) {
    self.init(context: context)
    property1 = (dictionary["key"] as? String) ?? ""
    // More properties...
}

Pour se débarrasser de l'erreur, j'ai ajouté une carte de méthode d'instance (dictionnaire: NSDictionary) et l'erreur de faute de segmentation a disparu.

convenience init(dictionary: NSDictionary, context: NSManagedObjectContext) {
    self.init(context: context)
    map(dictionary)
}

Pour moi, le problème était que mes architectures ne respectaient pas les normes. J'avais ajouté i386 ou quelque chose du genre, il suffit de le remettre à l'arc xcodeproject par défaut et il s'est bien compilé.

J'ai eu le même problème dans un projet rapide. Le problème était une fonction qui aurait dû renvoyer un objet, mais qui ne contenait pas de retour. Ce type d'erreur était signalé lors de l'édition avec Obj-C. Il semble que ce ne soit pas le cas dans Swift.