Facebook rend RacerD open source

Facebook rend RacerD open source
L’outil de débogage en programmation concurrente prend Java en charge, C++ à venir

Avec l’augmentation du nombre de processeurs/cœurs au sein des plateformes matérielles, il va de soi que les développeurs sont de plus en plus confrontés à la mise sur pied d’applications capables de tirer parti de ces architectures et donc d’effectuer plusieurs tâches en parallèle. D’avis d’experts, la tâche est ardue surtout lorsqu’il s’agit de dénicher des bogues. Fort heureusement, à l’ère de l’open source, il suffit d’un atterrissage sur le bon dépôt en ligne et l’on trouve solution à son casse-tête.

Pour le débogage d’applications mettant en scène des processus concurrents, les développeurs peuvent allonger la liste d’outils dont ils disposent avec RacerD. L’outil est accessible via le dépôt Infer de GitHub publié par Facebook sous licence BSD. Infer est un outil d’analyse statique de code Java, C++, Objective-C et C. Le lancement de RacerD requiert l’exécution de la commande infer --racerd-only -- javac nom du fichier.java pour s’assurer que seuls les résultats de l’analyse effectuée par l’outil soient affichés. RacerD prend uniquement le code Java pour le moment. Facebook annonce que d’autres langages (Java, C++, Objective-C, C, etc.) suivront.

RacerD est basé sur une technique dénommée « logique de séparation concurrente ». D’après Facebook, la mise en œuvre de cette dernière permet de détecter l’accès concurrent à des données par des processus sans qu’il soit nécessaire que le programme qui provoque leur activation soit exécuté. La technique a aussi un impact sur le temps nécessaire pour mener une telle analyse en comparaison aux méthodes dites par « force brute ». D’après Facebook, l’outil est capable d’analyser un million de lignes de code mettant en œuvre des accès concurrents en 15 minutes là où il faudrait 3,4 millions d’années pour analyser 80 lignes du même code par la force brute.

RacerD a été testé en production sur l’application Android liée au fil d’actualités de Facebook en 2016. D’après le géant d’Internet, l’outil a permis de détecter 1000 bogues d’accès concurrents aux données avant que la version multiprocessus du fil d’actualités ne soit lancée. Le passage à la version multiprocessus aurait mené à une augmentation de 5 % des performances de l’application Android liée au fil d’actualités. Toutefois, il convient de souligner que dans sa forme actuelle, l’outil a été taillé sur mesure pour donner satisfaction aux ingénieurs de l’équipe de développement Android dans de brefs délais. Il serait donc prudent de l’utiliser en combinaison à d’autres pour contourner les failles qui, logiquement, sommeillent encore en son sein.

Source : GitHub, Facebook

Et vous ?

:fleche: Qu’en pensez-vous ?

:fleche: Utilisez-vous des outils similaires ? Si oui, lesquels ?

Je salue le partage de l'outil.

Mais ils ont vraiment découvert 1000 bugs d'accès concurrent ???
Visiblement soit leur application est une usine à gaz peu maintenue, soit elle a été développée par des personnes qui n'y connaissent rien en programmation concurrente...

Attention, à ce qu'il semble ce n'est pas réellement un outil de deboggage, mais un outil d'analyse de code, c'est à dire un outil qui analyse la qualité du code. J'en ai essayé un une fois sur du C++ (sonarQube ?), qui me dit par exemple (de mémoire) :
- utilisation de (char *) alors que le paramètre attendu est (const char *) -> ok, important,
- conversion implicite de type (par exemple long vers int) -> ok, important,
- utilisation de #define -> je ne suis pas d'accord : il faut absolument éviter le code de type "#define max(a,b) ..." (remplacer par des fonctions inline qui en plus effectuent un contrôle de type) ou "#define gMyGlobal ..." (utiliser selon le cas des enums ou des static const) mais l'opérateur est irremplaçable dans bien des cas (#if TARGET== ...)

Pour résumer, ce ne sont pas 1000 bugs qui ont été détectés, mais 1000 "anomalies" ! Avec pour certaines des conséquences nulles car l'écriture a pu être volontaire.

Après avec Sonar (comme avec tous les outils du même type), c'est a toi (enfin à celui qui configure le serveur de Sonar/etc.) d'adapter les règles selon ce qui a été décidé pour le projet, sinon il prend en compte des règles par défaut qui ne sont peut etre pas suivies.