Aventure de développeur : un déboggage de débogueur

Florent Morin |

Quand on a besoin de voir ce qui se passe à l’exécution du code, le débogueur est un outil formidable. Dans le cadre d'un développement iOS, on utilise le débogueur LLDB fourni avec Xcode. On met un point d’arrêt là où il semble y avoir un soucis et on peut ensuite interagir directement avec le code au moment de l’exécution. C’est un outil formidable, sauf quand il ne fonctionne plus. Et c’est exactement l’aventure qui m’est arrivée cet été : une saga pleine de péripéties qui se termine par une fin heureuse, comme on les aime.

Le moment du drame : LLDB refuse de fonctionner

Nous étions donc avec un client au printemps quand nous avons décidé de migrer notre code sur une version plus moderne de Xcode, en l’occurrence la version 13.4. Tout se déroulait à merveille, jusqu’à ce que la machine se grippe : le débogueur LLDB ne voulait plus débogguer une partie du code. D’après les forums des développeurs Apple, le problème datait un peu et concernait un public assez limité comme je l’expliquerai plus loin. Plutôt que de perdre un temps plus précieux que les bénéfices de Swift 5.6, nous avons choisi de repousser cette migration.

Le début de l’aventure

Tout cela ne m’a pas empêché de creuser un peu plus ce sujet fort intrigant sur mon temps personnel. J’ai donc conçu un projet de démo permettant de reproduire le problème à coup sûr en limitant la quantité de code environnant qui pourrait brouiller la résolution.

En premier lieu, pour reproduire ce problème, il faut utiliser LLDB. En effet, plutôt que de mettre un point d’arrêt, nombre de développeurs se contentent d’exécuter la commande print() un peu partout dans le code et recompilent le projet jusqu’à ce que la source du problème soit débusquée. Également, il faut que l’app en question utilise des frameworks ou bibliothèques internes ou externes (CocoaPods inclus) et que le développeur souhaite débogguer ce code. Il faut aussi que ce code soit compilé statiquement : c’est généralement un avantage en termes de performances. Enfin, cela ne concerne pas les paquets Swift qui sont la manière officielle de modulariser le code selon Apple et qui bénéficient d’un meilleur accompagnement du constructeur. En gros, sont concernés les professionnels qui sont prêts à mettre les mains dans le cambouis.

J’ai donc conçu un projet décliné selon les différents cas de figure :

  • une bibliothèque statique
  • un framework compilé statiquement
  • un pod interne configuré pour générer un framework compilé statiquement
  • un code minimal utilisant Xcode en lignes de commande pour la compilation.

En parallèle, j’ai aussi créé une déclinaison utilisant des paquets Swift afin de m’assurer que cela ne vient pas de mon code Swift.

À ce stade, tout fonctionne jusqu’à Xcode 13.2.1. Ensuite, à partir de Xcode 13.3, ça ne fonctionne plus. J’ai donc l’exemple parfait, facile à débogguer et facile à comprendre.

La WWDC22 à la rescousse

Le printemps, c’est aussi l’arrivée de la WWDC et du nouveau Xcode, une arrivée à point nommé. Et là, première surprise : tout fonctionne de nouveau avec Xcode 14. Le premier automatisme est donc de se dire que c’était un bogue de Xcode 13.3 et 13.4. Mais en même temps, Apple a publié une session intrigante sur le déboggage du débogueur. Quel paradoxe ! D’un côté, le problème disparait avec Xcode 14. De l’autre, cette session fait état du problème que j’ai rencontré et apporte — au moins en partie — la solution.


avatar raoolito | 

"Avant d’aller geindre comme un enfant gâté"
Et aussi de crier au bug, donc...

La phrase "ca marchait toujours comme ca ya pas de raison que.." et une fois resolu "putain ils ne pouvaient pas laisser en l'etat"

Ben non, il faut evoluer, la technique de la roue carrée ou de la roue ronde, ca a pas ete simple d'échanger mais après un certain temps d'adaptation on y gagne à coup sûr. et le pire c'est que beaucoup de choses sont accessibles sous reserve de creuser le sujet un peu.
si vous n'aviez pas décidé de voir ca plus précisément hors de votre boulot pur, vous n'auriez jamais decouvert la solution, et le prochain projet pourra en profiter. alors que (trop) d'autres fois on aurait eu " on a essayé une fois on a fait marche arriere, now on ne le fait plus" (suivi généralement d'un commentaire genre "apple c'est plus ce que c'etait comme du temps de jobs" ) ce qui est logique quand on ne veut pas passer plus que ses heures de travail sur un sujet.
Ce n'est pas un combat simple, on doit negocier avec sa famille proche, l'envie de se divertir, les charges de travail, les fins de semaine, les amis et j'en oublie, mais c'est, a mon avis, la vraie morale de l'histoire: soit on veut aller de l'avant et cela demande des sacrifices, soit on ne veut pas, ok ca se defend, mais on ne se plaint pas!!!!!!!!!!!!!

Merci Florent, dès le titre de l'article je me suis douté que ca venait de vous ^^

avatar Florent Morin | 

C'est vrai que la vie personnel en a toujours fait les frais. Mais c'est le métier qui veut ça. Pour les agriculteurs ou ceux qui travaillent de nuit, c'est autre chose !

Et il y a aussi et avant tout la passion, qui comme toute passion est dévorante. L'important est de faire la part des choses.

Personnellement, je limite ce temps passé à 5 heures par semaine. Et ce n'est pas prioritaire au reste, sauf s'il y a un enjeu professionnel majeur. ça oblige à mieux s'organiser, de fait.

avatar raoolito | 

@FloMo

je ss un peu bourrin sur ce sujet, je considere que la vie de famille ou personnelle sans boulot est condamnée au désastre, humainement comme financierement. Alors évidemment c pas simple (et limiter à 5h/sem c pas mal) et dans "boulot" j'ai ajouté les vies associatives, parent d'eleve, etc.. mais le coeur, c'est le metier.

Tout un sujet, loin de celui de cet excellent temoignage-article ;)
Merci Flomo !

avatar Florent Morin | 

@raoolito

Avec plaisir. 😉

avatar Derw | 

@raoolito

Si c’est une passion, on sort un peu du cadre professionnel pur : de la même façon que l’on peut prendre du plaisir dans un loisir, une activité avec sa/son conjoint(e), ses enfants, ses amis… on peut prendre du plaisir sur une activité « professionnelle » qui déborde. Par contre, c’est un « plaisir solitaire » et il faut faire attention à ce que cela n’impacte pas trop les autres (amis, enfants…).

D’un autre côté, un travail informatique devrait toujours proposer du temps de veille sur son temps « officiel ». Personnellement, je passe entre 1 à 2 heures / semaine (mais pas toutes les semaines, cela dépend de la charge prioritaire) pour faire cette veille. Par ailleurs, tout travail (informatique ou non) doit aussi prévoir du temps d’entretien de ses outils sur ce temps de travail « officiel »…

avatar raoolito | 

@Derw

Oui effectivement
Mais c'est la théorie ;)

avatar Derw | 

@raoolito

Dans la pratique, j’ai toujours eu ce temps chez mes clients à contrats longs (plus d’un mois). Chez mon client actuel il y a une ligne d’imputation « veille » dans le système de saisie du temps de travail. Et la seule fois où ce n’était pas prévu, j’en ai parlé, et cela n’a pas posé de problème.

avatar cassis2k | 

Merci pour ce retour d’expérience 👍🏻

avatar Florent Morin | 

😊

Si ça vous plait, je pourrais en faire d'autres.

avatar Nebukad | 

Par curiosité, à combien de temps s'est élevé l'investissement sur le temps personnel pour ce bug ?

avatar Florent Morin | 

@Nebukad

Entre 10 et 15 heures au total je dirais. Lissées sur plusieurs semaines.

avatar Nebukad | 

@FloMo

Merci pour ce retour d'information et pour l'article. Vraiment intéressant.

avatar Nico_Belgium | 

Personnellement je n’ai jamais eu de réponses à un ticket déposé sur un bug iOS 🤷‍♂️ et ce n’est pas faute de les documenter avec des captures d’écran et/ou des snipets de codes (ce qui n’empêche que parfois ils sont résolus. Mais le ticket reste désespérément ouvert).

Je me demande comment ils traitent leur ticket. Comment sont choisis ceux qui sont traités (car il y a de toute évidence une forme de sélection qui est opérée)

avatar Florent Morin | 

@Nico_Belgium

Ça ne marche pas à chaque fois, hein !
J’ai quelques tickets en attente depuis des lustres.

Ce qui est sûr, c’est que le boulot doit être prémâché et toutes les alternatives possibles étudiées.

Ensuite, il y a aussi la fréquence du bug qui rentre en considération.

Et la forme compte aussi. Si on arrive d’emblée avec un ton accusateur et/ou campé sur ses positions, c’est mort.

avatar gwen | 

Article passionnant même si j’ai du mal à saisir certaines subtilités mises en avant, n’étant pas développeur. Mais c’est quand même agréable à lire et c’est ça la force d’un récit bien écrit.

Ça doit être cette clarté et concision qui ont fait qu’Apple se soit penché sur le problème. 👏

avatar Florent Morin | 

@gwen

Merci. 🙂

avatar DG33 | 

@gwen

Exactement le même avis. Pas développeur donc la partie technique bof, mais le rédactionnel est parfait, un plaisir à lire et découvrir une tranche de vie de développeur.

avatar titi17 | 

Super article, j’espère que l’on en aura plusieurs de ce type.

avatar Florent Morin | 

Merci. C'est noté.

avatar Upsilona | 

Pour moi qui suit resté au C++ tout cela me parait très / trop développé 🤢

CONNEXION UTILISATEUR