Je suis en train de déboguer un problème sur OS X qui ne se produit que lorsque l'application est démarrée à partir du dock. Cela ne se produit pas lorsque l'application est démarrée à partir de la ligne de commande. Quelle est la différence entre les deux scénarios? Le code avec lequel je travaille est un plug-in groupé basé sur C++ qui est chargé dans une application tierce. J'ai attaché au processus avec GDB dans les deux scénarios et la seule différence que je peux voir est que quelques dylibs supplémentaires sont chargés dans le processus en cours d'exécution à partir de la ligne de commande et que l'adresse de base de ma bibliothèque est légèrement différente dans le deux scénarios. J'ai essayé de changer mon lien à -prebind et/ou -bind_at_load en vain.Quelle est la différence entre démarrer un processus à partir du dock par rapport à la ligne de commande sous OS X
Répondre
Une différence importante est que le répertoire de travail initial sera différent dans chaque cas. Les applications ne devraient jamais faire de suppositions sur le répertoire de travail et se casser de façon intéressante si elles le font.
Basé sur plus d'enquête, je commence à penser que le problème est un problème de corruption de mémoire et le symptôme "seulement du quai" est un faux-fuyant. Bien que cela ne semble pas être le problème dans mon répertoire de travail différent est certainement quelque chose que j'ai regardé quand j'essayais de trouver des possibilités. Merci pour le conseil! –
Une application lancée à partir de l'icône Dock ne récupère pas les mêmes variables d'environnement qui peuvent être définies dans le shell que vous utilisez. Si vous comptez choisir quelque chose dans l'environnement, vous devrez chercher une approche différente. Vous obtiendrez quelques-unes des vars d'env, comme PATH, HOME, LOGNAME, etc. Mais si vous cherchez HOSTTYPE, LANG, OSTYPE, et al, ils ne seront pas présents.
Dans mon cas, mon problème était dû à une différence dans l'ordre de chargement des bibliothèques partagées. L'une des bibliothèques tierces utilisées par notre application charge les bibliothèques d'extension dans un espace de noms global. Il y avait des conflits de symboles avec une version différente de cette même bibliothèque. L'ordre dans lequel les bibliothèques d'extensions sont chargées dans le pool global change selon que l'application est démarrée à partir du document ou de la ligne de commande.
Dans une situation similaire, j'ai un plantage lors de l'exécution à partir de l'ensemble d'applications. Une possibilité est que nous utilisons la mémoire que nous avons déjà désallouée. Par exemple. en utilisant un pointeur ou un champ d'une classe après free() ou delete.
Il semble que les ensembles d'applications soient liés dynamiquement à une autre implémentation free/delete qui met à zéro/modifie la mémoire désallouée. Ce type de bug peut ne pas apparaître avec d'autres plateformes/compilateurs (par exemple Linux/gcc, Windows/Visual Studio, macOS/clang depuis la ligne de commande) et n'apparaître que lorsque le programme est exécuté à partir d'un ensemble d'applications (macOS/clang du Finder/dock).
Il serait beaucoup plus utile si vous nous disiez quel est le problème, B. quel est le comportement attendu, et C. ce qui se passe réellement. –
+1. La question est valide en elle-même: "Quelle est la différence entre démarrer un processus depuis le dock et la ligne de commande sous OS X", indépendamment de ce que Josh expérimente. – z5h
Malheureusement, je travaille ici comme un "homme du milieu" pour aider un de nos partenaires à résoudre un problème avec leur bibliothèque ... pour laquelle je n'ai pas de code bien sûr :) Il a fallu du temps pour obtenir de meilleurs détails. Concrètement, ce qui se passe est que pour le caractère unicode «DROIT UNIQUE DE COTATION DE COTATION», la fonction «unorm_normalize» de icu4c renvoie une erreur, mais seulement lorsque l'application est lancée à partir du dock. –