9
votes

Code exc_bad_access = 2 sur l'inclusion de Firebase / Auth dans Podfile

Je reçois Exc_bad_access après y compris 'Firebase / Auth' dans Podfile. Cela se produit sans ajouter de ligne de code Firebase. J'utilise SWIFT3 sur Xcode 8 et les gousses résultantes sont -

Installing Firebase (3.8.0)
Installing FirebaseAnalytics (3.5.1)
Installing FirebaseAuth (3.0.6)
Installing FirebaseCore (3.4.4)
Installing FirebaseInstanceID (1.0.8)
Using GTMOAuth2 (1.1.4)
Using GTMSessionFetcher (1.1.7)
Using GoogleAppUtilities (1.1.2)
Installing GoogleInterchangeUtilities (1.2.2)
Using GoogleSignIn (4.0.1)
Using GoogleSymbolUtilities (1.1.2)
Installing GoogleToolboxForMac 2.1.0 (was 2.1.0)
Using Localize-Swift (1.6)
Using ProtocolBuffers-Swift (3.0.6)
Using QorumLogs (0.9)


4 commentaires

J'ai eu une question après Updatinag Google Sign dans le cadre


Je résolve le problème par Downgrade Google Framefork vers la version 2.0.4: Pod 'Google / Signin', '2.0.4'


Pouvez-vous s'il vous plaît ajouter une stacktrace pour aider à déboguer le problème? Merci


Il va dans une boucle sans fin appelant Fira_ViewDidAppear :, une catégorie par Google / Firebase.


3 Réponses :


15
votes

Il semble y avoir un problème dans la dernière version Firebase / Core (3.8.0). Même @ibdesignable code> s'écrase avec un appel récursif à la signature de méthode que vous avez mentionnée.

Vous avez quelques options: P>

  1. in info.plist (app), définissez FirebaseautomaticsCreeenReportingEnabled code> à NO (BOOL). Cela a résolu le problème de mon application en cours d'exécution, mais des ressources ibdesignables ont provoqué cette erreur sur la construction: li> ol>

    Fichier: ///path/to/project/base.lproj/main.storyboard: Erreur: IB Designables: Impossible de rendre et de mettre à jour le statut de mise en page automatique pour UIViewController (SVZ-78-1MN ): L'agent s'est écrasé code> p>

    1. Vous voudrez peut-être dégrader temporairement sur 3.7.1, par exemple P>

      pod 'Firebase/Core', '~> 3.7.1'
      pod 'Firebase/Auth'
      pod 'Firebase/Database'
      


7 commentaires

@ADARSH J'ai passé un temps considérable avec le soutien de Firebase essayant de résoudre ce problème. Ils ont fourni un travail hacrain-autour de ce que je ne suis pas satisfait de (impliqué pour modifier des drapeaux de liaison) - bien que la demande fonctionnerait, les cocoapodes se plainent et les constructions d'unités d'unité ne compileraient pas. J'ai enfin essayé des dépendances Cocoapod W / FB personnalisées, mais cela semble non pris en charge par Cocoapodes (j'ai déposé ici: github.com/cocoapods/cocoapodes/issues/6138 ). Ma dernière résolution me fait mal, mais je comprendrai directement mon code-cadre dans la cible de l'application jusqu'à ce qu'il y ait une solution légitime pour notre problème.


Je devrais aussi ajouter - l'accident était à cause des erreurs mentionnées dans la réponse de @ Alex-D - la "mise en œuvre dans les deux". Une fois que ce bogue est effacé, il n'y a plus de panne. C'est pourquoi le support Firebase a suggéré de modifier manuellement des drapeaux de liaison. Techniquement, cela fonctionne, mais semblait trop important d'un piratage, de ne pas mentionner que les constructions de test de l'unité ne font toujours pas été abordée.


Je conviens que le problème de base semble être en raison de la «dépendance en double» créée en raison de la cible-cadre. Cependant, je ne vois pas comment les applications des clients dépendent toujours des objectifs de cadre (AS @ Alex-D suggérées), est une solution propre. Cela dit, cela signifie que cela est fondamentalement une question de cocoapodes / iOS que celle de Firebase.


Comment osez-ils ajouter une telle caractéristique "AutomaticscreenReporting" et la définition par défaut sur Oui ?????


J'ai reçu une certaine indication de l'équipe Cocoapods selon laquelle il y a probablement un problème avec la carte Podspec / Module. Tout cela est en désordre.


Je déteste simplement toutes les choses magiques qui se passent automatiquement à l'arrière-plan. Quand les choses invisibles cessent de travailler, vous ne voyez pas ce qui ne va pas.


C'est toujours un problème dans Firebase / Core 3.11.0



1
votes

Je soupçonne que le podfile n'est pas correct. J'ai eu un problème similaire en ajoutant une dépendance en Firebase dans un cadre et j'ai couru dans le problème comme celui-ci

objc [12345]: La classe Firaappenvironmentitil est mise en œuvre dans les deux /Users/....build/products/debug-iphonesImulator/someframework.framework/someframework (0x105EF7FC8) et /USERSERS/.../CURRENTPROJECT.App/CurrentProject (0x105945108). Un des deux sera utilisé. Lequel est indéfini.

Comme mentionné dans cette POST , vous pourriez avoir des dépendances en double dans différentes cibles pouvant conduire à un bug étrange comme celui-ci. Ajout de la caisse de Firebase dans la cible principale et enlever le pod en Firebase à partir du cadre fixe le problème pour moi.


2 commentaires

Si le cadre dépend du gousson, la cosse doit être dans la ou les cible appropriée. L'inclusion simplement dans la cible d'application n'est pas suffisante.


Je pense que les clients (applications) doivent tirer les SDK lorsqu'ils consomment les cadres pour éviter des dépendances compliquées. Selon ce Github.com/jverkoey/ios-Framework/issues/46 Il semble recommandé d'avoir les SDK au niveau de l'application, pas de niveau cadre.



1
votes

J'ai fait une erreur idiote. Jamais activé Google sous authentification -> Connexion Méthodes sur Firebase


0 commentaires