Blog Haypo

Le gestionnaire de code source git a été lancé en 2005. Depuis sa création, de nombreuses extensions et patchs ont été écrits. Du coup, je tombe régulièrement sur des informations contradictoires lors que je cherche comment faire tel ou tel truc dans Google. Quand j'arrive enfin à faire ce que je veux, je le note pour pas l'oublier :-)

Aujourd'hui, les astuces permettent de modifier les commits précédents. Je m'en suis servi sur un dépôt git-svn pour corriger des soucis avant d'envoyer (git svn dcommit) mes modifications upstream. Attention à ne pas modifier des commits déjà envoyés upstream par contre, sous peine d'avoir de gros conflits.

Supprimer un commit git

Si on réalise après coup qu'un commit est foireux, il peut être utile de le supprimer pour éviter de l'envoyer upstream. Dans mon cas, je devais supprimer un commit et non pas l'annuler (revert) car un script svn en pré-commit me bloquait.

La commande pour supprimer le commit numéro XXX :

git rebase --onto XXX~1 XXX

Rééditer le changelog du dernier commit git

Ça arrive de faire une faute de typo, mais de s'en rendre compte qu'après avoir fait le commit. J'ai toujours voulu pouvoir éditer un changelog à posteriori. C'est possible avec svn (sur le serveur), mais c'est très compliqué. Avec git, on peut facilement éditer un changelog, mais uniquement celui du dernier commit.

La commande pour éditer le changelog du dernier commit :

git commit --amend

Il exite également « git commit -c XXX » et « git commit -C XXX » mais je n'ai pas réussi à m'en servir :-(

When you're not allowed to commit in a svn repository, it's sometimes difficult to write an huge patch or to maintain an old patch. If the svn is updated while you're working on your patch (or after you wrote your patch), it will be difficult to update your patch. The main problem is that a patch has no reference to the revision number of the patched files. Your patch may apply to svn rev 67001 but not on svn trunk (rev 67103).

That's why I want to try git to be able to easily update a patch to the svn trunk. This article is a quick tutorial to setup your local git repository using git-svn.

Lire la suite

Histoire de ne pas les perdre, j'ai mis en ligne les différentes présentations que j'ai données depuis 2005 : voir toutes mes présentations. Vous y trouverez les supports (diaporamas) des présentations, si possible l'enregistrement vidéo, et les documents utilisés (pour les ateliers). Présentations archivées :

• 2008 : Présentation de Fusil le fuzzer aux RMLL
• 2008 : Présentation de PyPy et de Python 3000 à Pycon FR
• 2007 : Divers présentations sur la programmation Python (style du code, gestion des exceptions et des erreurs, écriture d'un module, les tests) aux Journées Python Francophones
• 2005 : Atelier sécurité sur PHP et SQL
• 2005 : Atelier sécurité sur le langage C

Les présentation sont au format Beamer ou S5. Je suis déçu d'avoir perdu les traces de mes ateliers XHTML/CSS et sur Gimp que j'avais donné à mon école (UTBM). Tant pis.

En juin 1998, Larry McVoy propose une nouvelle API pour les entrées/sorties dans le noyau Linux : The splice I/O model. Il propose une interface d'entrée/sortie vectorielle (scatter/gather), asynchrone et sans copie (zero copy). Le but est de maximiser les performances en évitant de recopier inutilement des zones mémoires. Les travaux pour concrétiser ses idées prendront presque une dizaine d'années.

Lire la suite

Lorsqu'on cherche à accélérer une application, on a besoin d'outils pour en mesurer les performances : isoler les fonctions les plus lentes et suivre l'évolution des performances. La méthode la plus simple est de sauver une estampille de temps au début et à la fin de l'opération testée, puis de calculer la différence en répétant la mesure pour la fiabiliser. Cette méthode est loude à utiliser car il faut modifier le code source. Je vais vous présenter des outils plus simples pour PHP et Javascript.

PHP : Xdebug

L'outillage PHP est rare et de piètre qualité. Néanmoins, je suis tombé sur XDebug qui, pour une fois, semble d'excellente facture. Ce projet est un extension PHP au moteur Zend qui permet de mesurer les performances d'un script PHP, d'analyser la couverture de code, ou encore de déboguer interactivement un script.

Pour compiler le projet sous Linux, vous aurez besoin de l'outil phpize qui va générer le script configure. Cet outil fait parti du paquet Ubuntu php5-dev. Bizzarement, Ubuntu (/usr/lib/command-not-found) ne propose pas d'installer le paquet php5-dev quand on tente d'exécuter phpize. Incapable de corriger le problème, j'ai ouvert un rapport de bug.

Une fois le module installé (./configure && make && sudo make install), il faut l'activer en ajoutant une option zend_extension à PHP. Sous Ubuntu, il suffit de créer un fichier /etc/php5/conf.d/xdebug.ini avec le contenu suivant (adaptez le chemin si besoin est) :

# configuration for php Xdebug module
zend_extension="/usr/lib/php5/20060613+lfs/xdebug.so"
xdebug.profiler_enable=1

Maintenant, pour chaque hit sur une page PHP, un fichier /tmp/cachegrind.out.pid sera généré. Les résultats peuvent manipulés avec l'excellent KCacheGrind. Un des graphiques les plus utiles est l'arbre ci-dessous :

Note : Pour l'installation, je me suis aidé du guide Installer Xdebug pour PHP 5.2.

Javascript : Venkman et Firebug

Pour profiler Javascript, là encore, il y a peu d'outils. J'ai testé le débogueur Javascript Venkman dans Firefox. Malheureusement, j'ai rapidement été confronté à un bug Firefox : Venkman crashs on profiling after clearing profile data. J'ai perdu beaucoup de temps à isoler ce bug avec gdb et Valgrind. Et dire qu'un rapport de profiling Venkman est une longue page HTML incompréhensible...

J'ai perdu tellement de temps sur Venkman que je ne me suis pas aperçu que j'avais déjà la solution sous les yeux ! L'excellente extension Firebug contient déjà des outils de profiling Javascript. Pour profiler une page, activez Firebug, cliquez sur le bouton « Profile » (c'était vraiment sous mon nez), chargez la page à tester, puis recliquez sur « Profile ». Vous obtiendez un joli tableau synthétique où on peut changer la méthode de tri dynamiquement. Voir le tableau (tronqué) ci-dessous :

Note : Je n'ai pas eu le temps de tester Drosera qui est le profiler Javascript de WebKit.

Mots de la fin

Pour finir, petit rappel : une optimisation n'est profitable que lorsqu'on gagne plus de 5% (voir 20%). Parfois, un changement sera une légère accélération sur une machine, et un léger ralentissement sur une autre. Les micro-optimisations sont à bannir. Souvent, un algorithme qui convenait à de petites quantités de données se révèle avoir une complexité en O(n^2) voir O(n^3) et effondre les performances. Il faut alors changer d'algorithme. Autre méthode : limiter les appels aux fonctions lentes, en utilisant un cache par exemple.

J'adore GCC ! C'est une collection de compilateurs pour de nombreux langages : C, ObjectiveC, C++, Java, Pascal, Ada, Fortran, etc. Il n'est peut être pas le compilateur le plus rapide (quoique...), mais celui qui supporte le plus d'architectures (processeurs et systèmes d'exploitation). Il permet d'ailleurs de compiler pour une architecture différente du système hôte (cross-compilation). Exemples : compiler depuis Linux pour Windows, compiler depuis Linux sur un processeur IA32 pour un ARM, etc. Je pense également qu'il respecte au plus près les standards (comme ISO C99).

Options -Wall -Wextra -Werror

Chaque nouvelle version de GCC détecte un peu plus de bugs. Ils sont soit rapportés sous forme d'avertissements, soit sous forme d'erreurs (bloque la compilation). Par expérience, je vous conseille d'activer tous les avertissements et de les corriger au plus tôt. L'option « -Wall » est censée activer tous les avertissements (vu son nom)... mais il existe « -Wextra » qui active encore plus d'avertissements ! Notez que -Wextra s'appellait « -W » tout court pour les versions inférieures à GCC 4.0. Si vous êtes pointilleux, vous pouvez utiliser « -Werror » qui va traduire les avertissements en erreur. Ceci oblige à corriger les avertissements sous peine de ne pas pouvoir compiler le programme.

Avec « -Wall -Wextra -Werror » on pourrait penser que GCC a fait de son mieux, mais que neni ! Il existe encore d'autres options « secrètes » comme par exemple l'option « -Wconversion » qui est pourtant utile : elle détecte les conversions de type dangereuses. Je pense que cette option est désactivée par défaut car elle produit beaucoup d'avertissements dont une bonne partie de faux positifs.

Détails de quelques options

Si je ne me trompe pas, les options suivantes sont toutes activées par « -Wall -Wextra ».

• -Waddress détecte les comparaisons de pointeur (et non pas de la valeur pointée) comme dans « char *hello="Hello"; if (hello == "Hello") ... »
  • C'est le moment de revoir la vidéo humoristique sur les pointiiii : « Stanford CS Education Library: Pointer Fun With Binky »
• -Wuninitialized détecte l'utilisation de variable non initialisée : « char *x; printf("x=%s\n", x); »
• -Wunused détecte les varibles inutiliséees : « void rien() { char x = 42; } »
• -Wno-int-to-pointer-cast / -Wpointer-to-int-cast avertit des conversions implicites entre pointeur et entier : « void *x = NULL; int y = x; ». Ceci est problématique sur certaines architectures telle qu'AMD64 où un entier int fait 32 bits alors qu'un pointeur fait 64 bits !
• -Wparentheses et -Wmissing-braces proposent d'ajouter des parenthèses / accolades pour du code prêtant à confusion
• -Wformat détecte appels erronés à printf (argument manquant ou en trop, ou encore type incompatible) : « printf("Bonjour %s\n"); »

Notez que vous pouvez écrire « -Wno-(...) » pour désactiver un avertissement, comme par exemple : « -Wno-format ».

Lire également mon autre article sur GCC

Comme je commençais à accumuler pas mal de liens intéressants sur la gestion de la mémoire, je me suis décidé à écrire un article. J'espère qu'il vous sera utile, au moins pour la culture générale.

Multithreading et malloc()

L'implémentation actuelle du célèbre allocateur de mémoire malloc() de la GNU libc est peu performante pour un programme multi-threadé. En particulier, la mémoire se fragmente facilement et l'allocation de mémoire est donc de plus en plus lente. Google a développé sa propre version de malloc() : tcmalloc. Elle est disponible dans la suite google-perftools sous la nouvelle licence BSD. Côté points noirs, tcmalloc utilise directement 6 Mo au démarrage pour son usage interne, et elle ne rend jamais la mémoire au système !

La prochaine version de FreeBSD (7.0) aura aussi un nouvel allocateur de mémoire : jemalloc, écrit par Jason Evans. L'implémentation actuelle de de FreeBSD est celle de Poul-Henning Kamp : phkmalloc. Vous trouverez une présentation de jemalloc dans l'article What's cooking for FreeBSD 7? Lisez également le papier écrit par Jason en avril 2006 : A Scalable Concurrent malloc Implementation for FreeBSD.

Selon un benchmark « NetBSD versus FreeBSD », les performances restent stables au delà de 4 threads (sur une machine ayant 4 processeurs) pour le nouvel allocateur de FreeBSD, alors que pour NetBSD et Linux les performances s'écroulent. En utilisant tcmalloc, les performances de Linux sont similaires à celle de FreeBSD.

La version actuelle de la GNU libc utilise ptmalloc2, implémentation inspiré de celle de Doug Lea (dlmalloc) version 2.7. La nouvelle glibc (version 2.6) utilise ptmalloc3 : 3e version de ptmalloc, basée sur dlmalloc 2.8.3 (date de 2005).

Mesure de la mémoire des processus

En avril 2007, Matt Mackall présentait son travail sur la quantification de la mémoire utilisée par un processus au Embedded Linux Conference. Il part du constat que les valeurs données par le noyau Linux n'ont que pas/peu de sens.

Il propose un patch pour le noyau qui permet de compter le nombre de processus partageant une page mémoire. La quantité de mémoire utilisée par un processus est alors le nombre de pages mémoire non partagées plus le nombre de pages partagées divisé par le nombre d'utilisations. Exemple : si 20 programmes utilisent une bibliothèque KDE de 30 Mo, la bibliothèque pèsera 30/20 = 1,5 Mo pour chaque processus et non plus 30 Mo comme c'est le cas actuellement ! Ceci permettra d'avoir une meilleure idée de la répartition de la mémoire. LWN.net propose un article détaillant la présentation de Matt.

Aux dernières nouvelles (voir les prévisions météo de Linux), le patch devrait être intégré dans Linux 2.6.25. La dernière version stable de Linux est la 2.6.23 et la 2.6.24 est en cours de développement. Il faudra être donc être encore un peu patient (ou alors recompiler son noyau à la main ;-)).

Astuce : Pour mesurer l'utilisation de la mémoire vidéo par les applications graphiques, utilisez le programme xrestop plutôt que top ;-)

Ce que tous les programmeurs doivent savoir au sujet de la mémoire

Ulrich Drepper, actuel mainteneur de la GNU libc travaillant pour RedHat, a écrit un article détaillant sur 100 pages la mémoire de nos jours (2007) : What every programmer should know about memory. Il a contacté le site Internet LWN.net pour publier son article. Pour une lecture plus confortable, l'article est découpé en 6 parties :

• Memory part 1: Commodity Hardware Today
• Memory part 2: CPU caches
• Memory part 3: Virtual Memory
• Memory part 4: NUMA support
• Memory part 5: What programmers can do
• Memory part 6: What programmers can do - multi-threaded optimizations

J'ai commencé à lire la 1ère partie qui est d'une excellente qualité. Par contre, c'est extrêmement technique et très détaillé. La première partie présente l'organisation logique d'un ordinateur en se concentrant sur le/les processeurs, la mémoire, le northbridge et le southbridge. Merci à toady de m'avoir indiqué ce lien ;-)

Noyau Linux

Le site linux-mm.org (Linux Memory Management) centralise les informations sur la gestion de mémoire par le noyau Linux. On y trouve les projets en cours de développement comme advanced page replacement. On y trouve aussi de très bonnes informations sur le gestionnaire de mémoire Linux, comme par exemple les articles OOM Killer (mécanisme qui désigne quel processus tuer quand la machine n'a vraiment plus de mémoire) et page fault handling. Rik van Riel a d'ailleurs publié une lettre ouverte invitant les universités à faire de la recherche fondamentale sur la gestion de la mémoire. Les algorithmes utilisés ne sont plus adaptés aux machines actuelles !

Et Python ?

Le gestionnaire de mémoire interne de Python 2.3 et 2.4, pymalloc, est bogué. Il ne rend jamais la mémoire au système ! Lisez le billet d'Evan Jones pour en savoir plus. Evan Jones a justement corrigé ce bug et son travail a été intégré dans Python 2.5. Lisez l'annonce d'Evan Jones et l'annonce de Tim Peters sur la liste de diffusion python-dev. Tim Peters a repris le travail d'Evan Jones, l'a corrigé et l'a intégré à Python.

Pour finir, voici deux outils permettant de tracer l'utilisation de la mémoire : PySizer et Heapy. Je ne les ai pas encore testé, mais ils sont certainement très instructifs. Lisez également le papier Heapy: A Memory Profiler and Debugger for Python.

N'oubliez pas d'utiliser régulièrement Valgrind sur vos programmes pour traquer les fuites de mémoire !

J'avais déjà lu que le noyau Linux est un bon test pour une version de gcc. J'en ai maintenant la preuve avec une nouvelle démonstration de Linus Torvald. L'histoire commence avec un courriel du développeur noyau suractif Ingo Molnar le 2 octobre vers minuit. Six heures plus tard, Linus répond que c'est un bogue du compilateur gcc.

Il montre que le code en langage machine cité dans le Oops noyau recopié dans le courriel d'Ingo ne correspond pas au code source C du noyau :

Code: 89 45 f0 76 77 eb 7a 8b 55 ec 8b 4d ec 
89 f7 8b 02 89 c2 03 51 0c 29 c7 89 f0 89 79 
0c 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 
<8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 8b 45 
08 0f be d9 89 da e8

Il écrit :

Lookie here:
- the bug happens on this:
       char c = *p++;
- which has been compiled into
       8b 3a           mov    (%edx),%e
which is a *word* access.

Quarante minutes plus tard, Ingo répond qu'il demeure perplexe « hm, it's 4.0.2. Not the latest & greatest but i've been using it for 2 years and this would be the first time it miscompiles a 32-bit kernel out of tens of thousands of successful kernel bootups. ». Mais les échanges suivants avec d'autres interlocuteurs réussissent à persuader Ingo.

Je pense que le bogue gcc 4.0.2 a été rapporté mais je n'en ai pas trouvé les traces. C'est quand même un bel exploit de l'expertise Linus qui semble habitué aux bogues du compilateur.

Je travaille actuellement sur le projet Nuface pour INL. Environ cinq personnes travaillent ou ont travaillé sur ce projet écrit en PHP (3/4) et Python (1/4). Le qualité du code source laisse à désirer. Je fais de mon mieux pour simplifier le code tout en le rendant plus simple à comprendre, mais c'est une tâche difficile et pénible. J'ai alors cherché des outils pour m'aider dans ma tâche.

Analyse statique de code

J'ai cherché des outils d'analyse statique de code pour PHP. Malheureusement, je n'en ai trouvé que quatre : Pixy, SWAAT, php-sat et PHP String Analyzer (phpsa). Les deux premiers sont dédiés à la sécurité, ce qui ne m'intéresse pas (injection SQL et XSS). phpsa est un drôle de projet dont je n'ai pas compris l'intérêt, et j'ai donc finalement testé php-sat. L'installation est longue car il n'existe aucun paquet Ubuntu Feisty, ni pour php-sat, ni pour les nombreuses dépendances. Ordre dans lequel il faut les installer (de mémoire) :

• aterm (2.5)
• sdf2 (2.4)
• strategoxt (0.17)
• php-front (0.1pre401)
• php-sat (0.1pre344)

Une fois que j'ai terminé de tout compiler et installer, j'obtiens ce joli message :

$ php-sat -i index.php
[ php-sat | error ] invalid box:
        KnownString{SafetyLevel([KnownString])}

Je ne comprend rien à ce message d'erreur cryptique que j'obtiens qu'importe le fichier passé en argument. Ayant passé deux heures à tout installer, je suis plutôt déçu et décide d'abandonner. La bonne pratique serait de contacter Eric Bouwers, l'auteur de php-sat pour lui rapporter mon problème, mais je ne l'ai pas (encore) fait.

Note : L'outil SWAAT a l'air d'être un bon outil pour trouver rapidement des failles de sécurité dans vos applications.

Eclipse et PDT

Un ami — feth — m'a montré les fonctions de refactoring de l'environnement de développement Eclipse. Bluffé par la facilité de renommer une variable ou créer une sous-fonction, je me suis décidé à l'installer pour pouvoir l'utiliser sur du code PHP. Une petite recherche m'a guidé vers PHPEclipse et PDT. Le premier n'est plus développé en faveur du second qui est sponsorisé par Zend, entreprise à l'origine du langage PHP. Zend emploie Yossi Leon pour travailler sur ce projet à plein temps.

J'ai d'abord installé Eclipse via Ubuntu : c'est la version 3.2 qui est disponible. Or quand j'ai voulu ajouter le greffon PDT, j'apprend qu'il faut la version 3.3 d'Eclipse. D'ailleurs, je réalise au passage que PDT est sorti en version 1.0 le 18 septembre dernier, c'est donc tout frais !

J'ai alors installé Eclipse en téléchargeant Eclipse Classic (eclipse-SDK-3.3.1-linux-gtk.tar.gz). Pour importer le projet Nuface, j'ai d'abord installé Subclipse, le greffon Subversion.

Finalement, tout s'est bien emboîté : Nuface s'ouvre à merveille dans Eclipse additionné de Subclipse et PDT. Eclipse affiche directement des avertissements sur la documentation écrite en docbook (format basé sur XML). En corrigeant l'erreur sur le charset incorrect, il arrive ensuite à détecter les erreurs de DTD (docbook). Chapeau !

Enfin, quand je cherche la fonction de refactoring « créer une sous-fonctions » — après deux heures d'installation — je découvre que la fonction n'existe tout simplement pas ! Seule la fonction pour renommer une variable ou une fonction est disponible dans PDT 1.0. Or j'avais installé Eclipse uniquement pour cette fonction... grosse déception.

Plantage PHP

Pour finir en beauté, aujourd'hui j'ai trouvé un bug critique dans l'interpréteur PHP. J'ai mis trois heures à isoler un bug ridicule qui fait planter le processus Apache (child pid 12946 exit signal Segmentation fault (11)). Les détails du plantage sont disponibles dans mon rapport de bug (#42817). Je pense que vu la popularité de PHP, ce bug peut être une faille de sécurité.

PHP est à vomir

Étant un programmeur de longue date, je suis très déçu de PHP. Langage crée en 1994, sa dernière version majeure (PHP5) élimine quelques défauts du modèle objet et comble certaines lacunes (ex: gestion des exceptions). Mais PHP 5.2 ne supporte pas Unicode et est vraiment trop laxiste selon moi. En particulier, accéder à une variable indéfinie ou à une clé inexistante d'un tableau devrait être proscrit. Pour que la programmation en PHP soit supportable, il faut travailler dans un niveau d'avertissement maximum : « error_reporint(E_ALL); ». Je vous conseille de jetter un Å“il au fichier debug.php de Nuface, il contient en particulier un gestionnaire d'erreur écrit PHP (nuface_error_handler).

Bon, moi je vais retourner coder des tests unitaires pour SimpleTest... Pour information, la version CVS offre une méthode expectException(), nécessaire pour pouvoir tester les exceptions.

Suite à l'annonce de l'intégration de PCC dans NetBSD, je me suis intéressé aux compilateurs libres qui existent. En chatouillant Google et Wikipédia, j'ai obtenu cette petite liste :

• GCC (GNU Compiler Collection)
  • Licence GNU GPLv2 avec un poil de LGPL
  • Projet lancé en 1985 par Richard Stallman et développé aujourd'hui en partie par RedHat. Fait parti du projet GNU.
  • Intégré dans de nombreux IDE. Exemples : DJGPP (MS-DOS) ; MinGW, Cygwin et Dev-C++ (Windows) ; etc.
• PCC (Portable C Compiler)
  • Licence BSD
  • Projet lancé dans la fin des années 1970 par Stephen C. Johnson
  • Plus d'informations dans les commentaires de l'annonce linuxfr et des critiques de gcc
• Watcom
  • Logiciel libéré en 2003 : OpenWatcom (licence)
  • Logiciel propriétaire ayant pour origine un compilateur Fortran écrit en 1965 par des étudiants de l'Université de Waterloo (Canada). Une version optimisée pour le C et pour PC est apparue en 1988 (Watcom C 6.0). Lire l'histoire complète.
  • Compilateurs de tous les jeux MS-Dos de 1993 à 1996 (DOOM, Descent et Duke Nukem 3D, etc.)
• LLC (Local C Compiler)
  • Développé par Chris Fraser et David Hanson
  • Projet de l'Université de Princeton
  • Logiciel libre ?
  • Intégré dans l'IDE « Lcc-win32 »
• SDCC (Small Device C Compiler)
  • Licence GNU GPL
  • Projet lancé Sandeep Dutta et ouvert aux contributions (Sourceforge) en 1999
• TCC (Tiny C Compiler)
  • Licence GNU LGPL 2.1
  • Projet lancé par Fabrice Bellard en 2002
• TenDRA
  • Projet initié par la DERA (agence du département de la Défense du Royaume-Uni) au milieu des années 1990
  • Licence BSD

Cette liste est sûrement incomplète, mais je pense que les compilateurs libres les plus populaires y sont listés. Consultez également la liste des compilateurs C de Wikipédia anglophone. Il existe de nombreux compilateurs commerciaux dont certains sont gratuits sous certaines conditions : Microsoft (Visual Studio), Intel (ICC), Borland (Turbo C, C++ Builder), ...

Pour information, un programme C exécuté dans LLVM 2.0 (Low Level Virtual Machine) est 20% plus rapide que lorsqu'il est exécuté avec GCC 4.2. On peut donc supposer que LLVM a accès à des algorithmes d'optimisation auxquels GCC n'a pas accès (sûrement parce que GCC est statique alors que LLVM est dynamique).

Pour les plus passionnés, un lien utile : Linux Assembly.

Perso, je suis déçu que PyPy n'ai pas réussi à être plus rapide que CPython (l'implémentation de référence en C) car pourtant sa technologie était bien plus évoluée :-( Apparemment, PyPy est plus un laboratoire d'expérimentation qu'une implémentation optimisée de Python.