OSX Yosemite: main() non appelé

Salut,

Je viens d'identifier un problème qui me ronge depuis quelques semaines. J'ai une applic qui tourne depuis des années et dont le code n'a pas changé depuis plusieurs mois. Cependant quelques utilisateurs m'ont remonté l'info comme quoi cette appli ne tourne plus suite à une mise à jour vers MaxOSX Yosemite (10.10).

Après investigation, il s'avère que l'appli est lancée, elle reçoit son Process ID, elle apparait dans le Moniteur d'Activité, mais le main() n'est jamais appelé... Donc forcément elle affiche un taux d'utilisation CPU de 0%.

Aucun log dans la Console, pas de crash reporté, rien... aucune indication sur la cause.

Avez-vous déjà rencontré un tel problème?

Notez bien que le problème n'est pas systématique, seul 5 cas m'ont été remontés depuis un mois alors qu'il y a plusieurs milliers d'instances qui tournent à travers le monde, et plusieurs centaines d'utilisateurs déjà passés à MaxOSX 10.10.

Merci d'avance,

/Phil

Demande à ces utilisateurs quelles autres applications ils utilisent en même temps, quelle est la commande de lancement exacte, et si possible, des informations précises sur le noyau d'OS X.

Sans plus d'info, sauf un gros coup de pot, tu n'auras pas de réponse.

Leur demander gentiment d'avoir un accès remote sur leur machine ? :calim2:

Oui c'est ce que j'ai fait, j'ai un accès remote et c'est ce qui me permet de tirer les conclusions citées ci-dessus.

Là j'ai recompilé l'appli avec la dernière version de XCode et il y a un tout petit mieux: main() est appelé, exécute le printf() qui me confirme l'appel dans le terminal, mais s'arrête immédiatement ensuite. La commande suivante est une simple création de l'objet principal, pas d'allocation dynamique, rien qu'une bête instantiation d'objet. Et toujours pas de crash, aucun log, rien. Le process se bloque, point barre.

- Mon appli est un binaire exécutable (pas un .app) amené à être lancé automatiquement (c'est un user agent). Mais là pour les tests je l'ai débrayé du launchctl et j'essaye simplement de le lancer en ligne de commande. Je l'ai aussi renommé, des fois que... mais ça ne change rien.
- Ce problème ne survient que suite à une mise à jour vers Yosemite. Il n'a jamais été reporté suite un un déploiement sur une installation fraiche de Yosemite.
- Le fait de changer de version de XCode permet d'aller un peu plus loin (appel de main) mais n'empêche pas le process de se bloquer
- Aucun log d'exception ou de crash report dans la console. Cela dit il n'y a aucune raison, les premières lignes de code ne font rien qui puisse provoquer une exception ou un crash.
- aucun anti-virus, pas de restriction sur les applics signées (mon binaire est de toute façon signé)

Plus généralement, la question sous-jacente est: qu'est-ce qui peut provoquer le gel d'un process (0% CPU) dès son démarrage?

Pas moyen de faire un dump d'un processus en cours d'exécution sous Mac ? :weird:

Bien vu, j'ai envoyé un binaire compilé en debug à l'utilisateur et j'ai utilisé le bouton [sample] à partir de l'Activity Monitor pour obtenir une analyse du process.

En fait, le main est bien appelé et se déroule jusqu'à un appel système (ici un appel à MIDIClientCreate) qui reste bloquant. Bon alors il y a un paquet de printf ne sortent pas sur le terminal pour je ne sais quelle raison, mais c'est secondaire. Finalement le problème est dû à un driver d'une autre compagnie (Avid CoreAudio) qui n'est pas supporté par Yosemite. D'où la raison pour laquelle le problème survient lors d'une mise à jour vers Yosemite. Les utilisateurs ont une machine en 10.9 avec un driver qui fonctionne, ils font la mise à jour en 10.10, et là le driver par en vrille et emmène mon user agent avec lui. Comme mon soft est chronologiquement le premier à utiliser ce driver, et ben c'est sur ma poire qu'on tombe :-)

Bref, fausse alerte en ce qui me concerne.

Merci pour vos suggestions en tout cas. :plusser:

Citation:

---

Envoyé par CopperPhil

Bon alors il y a un paquet de printf ne sortent pas sur le terminal pour je ne sais quelle raison, mais c'est secondaire.

---

Faut flush (flusher?) la sortie pour qu'elle s'affiche à coup sûr

Content de voir que tu as une solution. Bonne continuation

@bousk: en français, on dit en général purger le tampon de sortie (flush output buffer)