Plantage avec NSSavePanel sous Yosemite

beebbeeb Membre
décembre 2015 modifié dans API AppKit #1

Réponse à  http://forum.cocoacafe.fr/topic/13662-crash-nsopenpanelnssavepanel-avec-yosemite/


 


Salut salut,


 


Je déterre un peu car j'ai le même souci avec mon appli. J'essaie en vain de publier une mise à  jour mais elle est refusée à  chaque fois à  cause d'une erreur identique. Ce qui est étrange, c'est que l'erreur est sensée venir de NSSavePanel d'après les logs, alors que je n'ouvre un NSSavePanel que lors d'une action utilisateur (clic sur un menu ou un bouton). Pourtant, mon app plante au lancement??


 


Mala tu as réussi à  passer outre? Je suis sous El Capitan donc pas facile de tester, le bug arrive apparemment uniquement sous Yosemite.


 


Merci (désolé si ce n'est pas ici que je dois poster mais ça semblait à  propos)


 


Modérateur: je l'ai extrait dans un nouveau sujet; je sens que le sujet va dériver.


«1

Réponses

  • CéroceCéroce Membre, Modérateur

    Pourrais-tu nous donner un extrait du log ?


    Ton appli est-elle distribuée sur le Mac App Store ?


     


    À noter que sous Yosemite, on a sans arrêt un message comme quoi NSSavePanel a fait merder les contraintes Autolayout. C'est un bug d'Apple qui n'a jamais été corrigé.


  • CéroceCéroce Membre, Modérateur


    Je suis sous El Capitan donc pas facile de tester, le bug arrive apparemment uniquement sous Yosemite.




    Tu n'as plus qu'à  installer un dual boot sur ta machine " du moins si c'est possible d'installer Yosemite sur ta machine.

  • MalaMala Membre, Modérateur
    décembre 2015 modifié #4


    Tu n'as plus qu'à  installer un dual boot sur ta machine " du moins si c'est possible d'installer Yosemite sur ta machine.




    Le souci c'est que si son appli a été codée sous El Capitan, il risque de pas pouvoir rétro grader au niveau d'Xcode pour passer un coup de débug. C'est vraiment devenu une galère innommable les problèmes de réto compatibilité pour les devs Mac. 


     


    Comme Céroce, peux-tu nous mettre le log? Dans mon cas, le problème touchait une poignée d'utilisateurs. J'ai comme l'impression que chez toi c'est systématique sous Mavericks non? En cas je peux te faire quelques tests si tu veux. Ma machine de devs est sous Mavericks et j'ai un disque avec tous les systèmes depuis 10.5.


  • Mala, Battu ! je peux faire tourner les OS depuis 10.2.8 (sur PPC !)


  • beebbeeb Membre
    décembre 2015 modifié #6

    Merci pour vos réponses !


     


    Premièrement voici les logs : http://pastebin.com/MuB6tQcx


     


    Ensuite, le programme n'est compatible qu'avec Yosemite et suivants car écrit en Swift et j'utilise pas mal d'APIs 10.10+. L'appli est sandboxée et je suis certain que mes entitlements sont corrects.


     


    Le problème survient sur 10.10.5 comme vous pouvez voir dans les logs. L'application est sur le mac app store et c'est lors de la validation par les gars de chez Apple que le problème survient. Pour ma part, j'ai testé la build sur 2 MacBookPro tournant sur 10.10.5 et je n'ai pas réussi à  avoir le bug, donc ce n'est pas systématique je pense (de là  à  savoir si les ordinateurs de test chez apple ont quelque chose de particulier..) Je peux pas installer xcode sur les 2 ordinateurs susmentionnés malheureusement.


     


    Petite précision encore : il n'y a aucun appel à  NSSavePanel dans mon "viewDidAppear". Seulement un appel à  NSOpenPanel. Pourtant les logs mentionnent NSSavePanel.


     


    Merci !


     


    EDIT: la première version était passée comme une lettre à  la poste, je sais pas si j'ai eu un coup de chance lors de la soumission de la première version mais lors des 2 dernières soumissions pour vérification ils m'ont envoyé le même log d'erreur (exactement à  l'identique).


  • CéroceCéroce Membre, Modérateur
    décembre 2015 modifié #7

    Tu pourrais résoudre les symboles de Squeed dans ton crashlog, et nous donner le code la méthode qui appelle -[NSPanel init] ?


     


    Par ailleurs, je vois que ton appli sert à  soigner une bibliothèque musicale, dont j'imagine qu'il y a bien un moment où l'utilisateur choisit le répertoire où elle se trouve. Avec le sandboxing, une appli ne peut pas accéder à  un répertoire externe sauf si l'utilisateur passe justement par NSSave/OpenPanel.




  • Tu pourrais résoudre les symboles de Squeed dans ton crashlog, et nous donner le code la méthode qui appelle -[NSPanel init] ?




     


    J'ai très envie de faire ça mais je ne sais pas comment faire! Je crois qu'il faut exporter les dSYMs mais quand je fais "Download dSYMs" dans la fenêtre avec les archives il me dit qu'ils ne sont pas disponibles au téléchargement.

  • CéroceCéroce Membre, Modérateur


    J'ai très envie de faire ça mais je ne sais pas comment faire! Je crois qu'il faut exporter les dSYMs mais quand je fais "Download dSYMs" dans la fenêtre avec les archives il me dit qu'ils ne sont pas disponibles au téléchargement.




     


    Non, c'est Xcode qui fait le rapprochement. Tu lui donnes le crashlog (dépose sur son icône), et lui va chercher le dSYM qui convient parmi ceux qui sont archivés.

  • beebbeeb Membre
    décembre 2015 modifié #10


    Non, c'est Xcode qui fait le rapprochement. Tu lui donnes le crashlog (dépose sur son icône), et lui va chercher le dSYM qui convient parmi ceux qui sont archivés.




     


    J'ai reçu un fichier .txt depuis iTunes Connect, j'ai essayé de le renommer en .crash et de l'ouvrir avec Xcode mais il me l'ouvre comme un fichier texte, j'ai dû louper une étape. Ce que je trouve sur internet utilise la commande symbolicatecrash et le fichier .dSYM.


     


    EDIT: Trouvé le dSYM dans l'archive!! je vais essayer de faire quelque chose avec ça


  • beebbeeb Membre
    décembre 2015 modifié #11

    Okay je dois symboliser 1 instruction à  la fois avec "atos" parce que symbolicatecrash veut pas fonctionner, mais j'ai réussi à  déterminer que le NSPanel.init() est appelé depuis ma méthode "openFolderDialog()" qui effectivement va ouvrir un NSOpenPanel (pas NSSavePanel!) lors du premier lancement de l'application. Cette méthode est appelée dans le "viewDidAppear" de mon ViewController principal. Voici le code de ma méthode (rien de bien méchant, je n'ai pas touché ce code depuis des lustres) :



    func openFolderDialog(message: String) -> Void {
    let myFiledialog: NSOpenPanel = NSOpenPanel()

    myFiledialog.prompt = NSLocalizedString("Choose", comment: "Choose the folder to open")
    myFiledialog.worksWhenModal = true
    myFiledialog.allowsMultipleSelection = false
    myFiledialog.canChooseDirectories = true
    myFiledialog.canChooseFiles = false
    myFiledialog.resolvesAliases = true
    myFiledialog.title = NSLocalizedString("Open", comment: "")
    myFiledialog.message = message
    myFiledialog.beginSheetModalForWindow(self.view.window!, completionHandler: { (result) -> Void in
    if result == NSModalResponseOK {
    let url = myFiledialog.URL
    if (url?.isFileReferenceURL()) != nil {
    var isDir: ObjCBool = ObjCBool(false)
    let fm = NSFileManager.defaultManager()
    if fm.fileExistsAtPath((url?.path)!, isDirectory: &isDir) {
    var bookmark: NSData? = nil
    do {
    bookmark = try url!.bookmarkDataWithOptions(NSURLBookmarkCreationOptions.WithSecurityScope, includingResourceValuesForKeys: nil, relativeToURL: nil)
    } catch let error {
    print(error)
    }
    if bookmark != nil {
    self.defaults.setObject(bookmark, forKey: "cdBookmark")
    self.defaults.synchronize()
    }

    self.cd = (url?.path)!
    self.defaults.setObject(self.cd, forKey: self.userCd)
    self.defaults.synchronize()
    self.getFilesList()
    }
    }
    }
    })
    }

  • CéroceCéroce Membre, Modérateur

    NSOpenPanel hérite de NSSavePanel.


     


    Bon effectivement, il n'y a rien de très évident là  dedans.


    Qu'est-ce que ce service d'Apple com.apple.view-bridge ?


     


    Au moins, tu n'es pas seul:


    http://stackoverflow.com/questions/26366711/nssavepanel-crash-in-sandbox-app-os-x-10-10

  • beebbeeb Membre
    décembre 2015 modifié #13
    La seule différence c'est qu'ils arrivent à  reproduire le bug, eux...
  • Pour essayer de reproduire l'erreur as tu essayé de supprimer toutes les fichier de préférences/container etc... correspondant à  ton application avant de la lancer ?


    Il y a aussi un cet autre post sur SO qui ne répondra certainement pas à  ton problème mais qui peut éventuellement aiguiller...


  • beebbeeb Membre
    décembre 2015 modifié #15
    Supprimer le Container ne me permet pas de reproduire le problème, même sur Yosemite quand j'ai pu tester la build sur les ordi de mes amis. Concernant la question SO, ils parlent de 10.10.2 et antérieurs, or on est sous 10.10.5 ici.. Mais à  voir, si la solution c'est de pas utiliser les storyboard je suis pas sorti de l'auberge..
  • A noter qu'une solution est présentée ici : http://stackoverflow.com/questions/26366711/nssavepanel-crash-in-sandbox-app-os-x-10-10: ne pas mettre la fenêtre comme point d'entrée du storyboard et afficher manuellement la fenêtre en chargeant le SB dans une propriété du AppDelegate. J'ai essayé mais ça me fout en l'air d'autres fonctionnalités donc si je peux éviter c'est mieux (spécifiquement, PowerBox bug dans certains cas et je ne vois plus les fichiers, même si j'ai chargé le bookmark correctement).


     


    Si il n'y a pas d'autre solution, je tenterai de corriger ce bug et de charger mon storyboard manuellement comme expliqué ci-dessus mais j'aimerais autant éviter.


  • MalaMala Membre, Modérateur
    décembre 2015 modifié #17

    Effectivement, j'ai comme l'impression que tu rencontres le même bug que moi (ref:18679387).  :)


     


    Je n'ai jamais réussi à  reproduire le bug chez moi non plus. Peux-être devrais-tu leur mentionner la réf du bug report.


     


    Le coup du passage via Storyboard c'est sacrément moyen tout de même comme pseudo solution.


     


    PS: est-ce que ton panel est customisé? J'entends par là  ajout d'une accessoryView pour les besoins de ton appli. Les miens oui.


     


    Edit: oublies mon PS, il y a rien dans ton code donc c'est pas lié non plus.


  • MalaMala Membre, Modérateur

    Au fait, dans mon cas avec MarScaper HDR, je n'utilise pas les storyboards donc j'ai tout de même un gros doute sur la véracité de cette solution.


  • beebbeeb Membre
    décembre 2015 modifié #19

    Mon panel est tout ce qu'il y a de plus standard, aucune personnalisation de mon côté ! La solution qui me semblerait la plus potentiellement acceptable est celle où il faut charger manuellement le SB car il y aurait une "mauvaise connexion" avec la fenêtre au niveau du WindowController (je cite: "That led me to believe that my app delegate had a major disconnect with the primary window being shown--especially now with storyboards having a separate Application Scene and WindowController.").


     


    Reste à  résoudre mes problèmes de PowerBox, mais ça c'est une autre histoire.


     


    EDIT: on dirait que mes bugs de powerBox sont partis, je vais donc essayer de re-soumettre comme ça !


     


    MERCI pour votre aide :)


     


    EDIT bis: ce que j'ai fait :


     


    Dans IB, je décoche la case "Is Initial Controller" sur ma fenêtre.


     


    Dans mon AppDelegate, je déclare une propriété:



    var rootController: NSWindowController? = nil;

    Ensuite dans sa méthode "applicationDidFinishLaunching", j'ajoute ceci à  la fin:



    let sb = NSStoryboard(name: "Main", bundle: nil)
    rootController = sb.instantiateControllerWithIdentifier("HomeView") as? NSWindowController
    rootController?.showWindow(self)

    A noter que ma fenêtre possède l'ID "HomeView" et mon SB s'appelle "Main".


  • Salut tout le monde, bonne année !


     


    Alors que je nageais dans le bonheur car mes builds étaient à  nouveau acceptées par l'équipe iTunes et que je croyais avoir résolu mon problème pour de bon: PAF ! Une mise à  jour mineure que j'ai soumise il y a quelques jours ne passe pas, pour l'exacte même raison qu'auparavant. Autant dire que je n'ai rien résolu et que je suis donc de retour à  la case départ...


     


    Pour rappel, l'instanciation et l'ouverture d'un NSOpenPanel au démarrage (dans mon viewDidAppear) fait soit-disant planter mon application sous 10.10.5 (je n'ai jamais pu reproduire le bug sur des ordinateurs tournant avec la même version de l'OS), selon les testeurs de Apple.


     


    Je crois que j'ai eu de la chance pour les quelques dernières builds, le testeur devait être sous 10.11 ou alors le bug ne se produit pas de manière consistante et je suis tombé quelques fois sur un ordinateur bien luné.


     


    Halp?


  • As-tu essayé de faire un dispatch sur thread principal de l'appel au NSOpenPanel ?




  • As-tu essayé de faire un dispatch sur thread principal de l'appel au NSOpenPanel ?




     


    L'appel se fait déjà  sur le thread principal. Ou alors je n'ai pas compris ta question?



  • L'appel se fait déjà  sur le thread principal. Ou alors je n'ai pas compris ta question?




    Peut être que faire l'appel de la fonction sur la prochaine boucle d'évènement, comme le suggère colas_, avec un dispatch_after permettrait au système de finir l'initialisation de certaines "choses" qui rentrent en conflit avec ton appel à  NSOpenPanel.

  • beebbeeb Membre
    janvier 2016 modifié #24


    Peut être que faire l'appel de la fonction sur la prochaine boucle d'évènement, comme le suggère colas_, avec un dispatch_after permettrait au système de finir l'initialisation de certaines "choses" qui rentrent en conflit avec ton appel à  NSOpenPanel.




     


    Ah, à  ce sujet j'ai oublié de mentionner que j'ai déjà  fait ça et mon problème persiste (faut-il mettre > 1 seconde de délai?) :



    let delay = 1 * Double(NSEC_PER_SEC)
    let time = dispatch_time(DISPATCH_TIME_NOW, Int64(delay))
    dispatch_after(time, dispatch_get_main_queue()) {
    self.openFolderDialog(NSLocalizedString("Please select a folder to scan for audio files.", comment: "")) //appel à  mon NSOpenPanel là -dedans
    }

  • MalaMala Membre, Modérateur
    janvier 2016 modifié #25

    Déjà  faisons le point sur les choses dont on est sûr ou quasi sûr:


    - le bug ne semble toucher que Yosemite (chez toi et idem chez moi).


    - impossible de reproduire chez nous (lien possible avec la langue du système?).


    - le bug touche aussi bien une appli sous Swift (pour toi) qu'en objective-C (dans mon cas) donc exit un bug de jeunesse de Swift.


    - les applis sont sandboxées pour passage sur le store.


    - le plantage n'apparait pas lors de l'ouverture du panel mais dès sa création (appel du init) donc exit les spéculations de dispatch.


    - le bug apparait sur un panel standard chez toi et customisé chez moi (accessoryView) donc pas de lien avec ça.


    - je n'utilise pas de storyboard alors que toi oui donc exit aussi à  mon sens.


     


    A ta place, la chose que je ferais c'est de garder la main avec le lutin qui te remonte le crash et de lui soumettre une version de ton App ou tu catches l'exception générée et tu l'affiches dans une boite de dialogue. Cela ouvrirait peut être une piste à  défaut de mieux dans l'immédiat.


  • LexxisLexxis Membre
    janvier 2016 modifié #26

    Tu peux essayer de logger ce qu'il se passe au niveau du "View Bridge" (voici un article qui parle de ce sujet). Peut être que cela ter permettra de voir de qui se passe exactement lorsque tout fonctionne (chez toi) et en déduire ce qui ne pourrait pas fonctionner chez les autres, qui sait...


     


    J'ai installé une machine virtuelle Yosemite. Je pourrais tester ton application, avec de la chance elle pourrait planter (hum...)




  • Tu peux essayer de logger ce qu'il se passe au niveau du "View Bridge" (voici un article qui parle de ce sujet). Peut être que cela ter permettra de voir de qui se passe exactement lorsque tout fonctionne (chez toi) et en déduire ce qui ne pourrait pas fonctionner chez les autres, qui sait...


     


    J'ai installé une machine virtuelle Yosemite. Je pourrais tester ton application, avec de la chance elle pourrait planter (hum...)




     


    Bonne piste, merci! J'ai activé globalement le logging de ViewBridge, mais je dois consulter quel fichiers log pour voir les résultats? Je n'ai jamais vraiment utilisé les logs système avant, je suis pas très à  l'aise avec ça.



  • A ta place, la chose que je ferais c'est de garder la main avec le lutin qui te remonte le crash et de lui soumettre une version de ton App ou tu catches l'exception générée et tu l'affiches dans une boite de dialogue. Cela ouvrirait peut être une piste à  défaut de mieux dans l'immédiat.




     


    Merci pour le résumé, c'est effectivement ça ! Comment est-ce que je peux garder contact avec le gars? J'ai déjà  répondu au message dans le Resolution Center mais ça n'a jamais donné suite à  une discussion...



  • Bonne piste, merci! J'ai activé globalement le logging de ViewBridge, mais je dois consulter quel fichiers log pour voir les résultats? Je n'ai jamais vraiment utilisé les logs système avant, je suis pas très à  l'aise avec ça.




     


    Les logs système (application Console). Par contre cela ne fonctionne qu'avec Yosemite.



  • Les logs système (application Console). Par contre cela ne fonctionne qu'avec Yosemite.




     


    Et pas El Capitan? J'ai essayé justement et rien n'apparaissait en rapport avec le ViewBridge dans system.log.

  • Apple semble avec supprimé (ou modifié) les loggings de ce Framework dans El Capitan.


Connectez-vous ou Inscrivez-vous pour répondre.