Xcode 11.4 - Projet d'archivage - Erreur de segmentation 11


12

Je viens de mettre à jour Xcode vers 11.4 et lors de l'archivage d'un projet, il me montre 'Erreur de segmentation 11'

Ce projet archiverait avec Xcode 11.3.1 mais maintenant ce n'est pas le cas.

Quelqu'un d'autre a rencontré le même problème?

entrez la description de l'image ici

Edit: 15 avril 2020

Apple vient de sortir Xcode 11.4.1


Jetez un oeil à ce post: stackoverflow.com/a/42168123/2583679
Tom

3
@ Tom merci, mais cela ne le résout pas .. je suis sûr que c'est un bug Apple
Artur Marchetto

Réponses:


11

J'ai rencontré le même problème. L'archivage utilise la configuration de la version Release, j'ai donc parcouru tous les paramètres du compilateur pour déterminer quelles différences entraînaient ces erreurs de segmentation.

Dans mon cas, le problème disparaît lorsque je modifie le paramètre Activer la testabilité sur OUI pour la libération .

Non, je ne sais pas quels sont les inconvénients de cela dans l'archive ou la version, ni même pourquoi ce paramètre particulier atténue le problème, mais au bout du compte, j'ai un projet qui a pris un an pour arriver à ce stade et je suis très désireux de le transmettre aux bêta-testeurs internes, je vais donc le soumettre via un vol d'essai et voir comment je vais.

Mon sentiment est que c'est définitivement un bug d'Apple, car le compilateur ne devrait pas du tout être Seg Faulting. Le fait qu'il compile sous la configuration de débogage prend en charge cela. Mon projet est si grand que je ne sais pas comment le reproduire pour soumettre un bogue, mais je vais voir si je peux obtenir une réponse sur les forums Apple.


Ran dans le même problème dans Xcode 11.4.1, la modification de ce paramètre a également fonctionné pour moi. Les docs disent que cet indicateur a à voir avec le fait de rendre les interfaces privées accessibles, donc peut-être qu'il y a quelque chose là-bas ... Lorsque ce paramètre est activé, le produit sera construit avec des options appropriées pour exécuter des tests automatisés, telles que rendre les interfaces privées accessibles au tests. Cela peut entraîner des tests plus lents qu'ils ne le feraient sans la testabilité activée.
keegan3d

5

Pour moi, j'ai aidé à trouver le problème lorsque j'ai défini les paramètres de construction SWIFT_COMPILATION_MODEsur wholemodule. Ensuite, après la compilation, une erreur plus spécifique a conduit à la fonction de classe qui a provoqué l'erreur. Ensuite, il l'a changé tel quel.

Peut-être que cela vous aide aussi.

Dans mon cas, un opérateur ternaire a été utilisé pour l'ensemble de paramètres d'entrée init. Il semble que Swift 5.2 ne le supporte plus.

// Leads to error with Xcode 11.4
init(value: UIColor = Constants.staticBoolean ? .white : .green)

2
Merci beaucoup!! tu as fait ma journée !!
nomnom

3
Cela corrige également mon erreur de temps de construction. Un opérateur ternaire dans les paramètres par défaut est le coupable. J'espère qu'Apple corrigera bientôt le bogue.
Dao Xiang

2
Je ne reproduis pas avec Swift master branch github.com/apple/swift/tree/master . Alors peut-être déjà réparé.
Cœur

1

Dans mon cas, j'ai eu une erreur avec le pod Eureka

Segmentation fault: 11 (in target 'Eureka' from project 'Pods')

Dans le fichier Pods, j'ai fourni la dernière version:

pod 'Eureka', '~> 5.2.1'

Définissez également SWIFT_COMPILATION_MODEdéfini sur wholemodule.


0

J'ai changé #imageLiteral(resourceName: "image_name")pourUIImage(imageLiteralResourceName: "image_name")


0

Comme d'autres intervenants, il y avait un problème SwiftUI enfoui dans les messages d'erreur ici (en utilisant Xcode 11.4). Dans mon cas, l'utilisation de .embedInScrollView()provoquait l'erreur de construction. La désactivation de ces appels l'a corrigé. Comme solution de contournement, j'ai mis .embedInScrollView()dans un ViewModifier, comme ceci:

public struct WrapInScrollView: ViewModifier {
    public func body(content: Content) -> some View {
        content
            .embedInScrollView()
    }

    public init() {}
}

Ensuite, j'utilise ce modificateur un peu comme l'appel d'origine, comme ceci:

.modifier(WrapInScrollView())

Cela signifie que vous pouvez toujours intégrer une scrollView mais les erreurs Seg 11 disparaissent.


0

Malheureusement, l' option Activer la testabilité solution n'a pas fonctionné pour moi.

Une solution temporaire (jusqu'à ce qu'Apple corrige le problème du compilateur Xcode 11.4 Swift) consiste à régler le niveau d'optimisation sur « Aucune optimisation » pour la version, sur la cible qui échoue (SWIFT_OPTIMIZATION_LEVEL = "-Onone"; ). Il fonctionne sur notre projet, qui est divisé en plusieurs cadres. Il suffit d'en régler un -Onone.

Mais la documentation Apple demande de ne pas envoyer votre code avec ce drapeau . C'est pour le développement, il effectue des optimisations minimales et préserve toutes les informations de débogage.

Je pense que nous devons attendre: »(


-1

Je recevais cette exception et les journaux d'archivage m'ont aidé à comprendre qu'elle se trouvait dans un fichier SwiftUI particulier. Par processus d'élimination, il s'avère que j'avais quitté contentInsets()et les alwaysBounceVertical()modificateurs sur un VStackqui ne faisait pas partie d'un List:

VStack {
    // more stuff
}
.contentInsets(UIEdgeInsets(top: 20, left: 0, bottom: 0, right: 0))
.alwaysBounceVertical()

La suppression de ces modificateurs a permis à l'archive des versions de se terminer avec succès.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.