Trouver un core dump ...

bin oui, parce que coder, c'est aussi chercher pourquoi un programme s'est planté. Linux est assez sympa sur ce coup-là avec son ulimit -c unlimited qui permet d'autoriser la production de 'core dumps' dans le répertoire courant pour un shell donné sans que tout le système ne se mette à saturer le disque dur en cas de dysfonctionnement. Après, on ouvre le dump dans un débuggeur et en avant pour l'autopsie.

Mais là, pas'd'bol, je suis sous Windows. Le boulot, vous comprenez. Le frangin de Jigé me proposait de faire clic-droit-debug dans le gestionnaire de tâches (onglet 'détails' de préférence, apparemment) et hop youpi, visual studio prendrait en marche le programme fautif. ça m'arrangerait assez bien vu qu'il est appelé depuis du python au bout d'une séquence de 3 ou 4 programmes histoire que la caméra à l'autre bout du fil soit dans les bonnes dispositions pour les tests. 

Mais re-pas'd'bol, quand je fais ça, j'ai juste droit à "not responding" sur Visual Studio puis les deux programmes qui s'arrêtent avec pas plus d'infos. ça marchait mieux avec "create dump file", mais ce n'est pas ce qu'il me faut aujourd'hui.

Pour le coup, je vais devoir refaire appel à devenv /debug dans une console VSpéciale et croiser les doigts pour être dans les bonnes conditions pour reproduire le crash. 

• c'est apparemment normal d'être accueilli dans un Visual Studio qui fait semblant de ne pas savoir ce que vous voulez. Debug>Start Debugging devrait nous mettre en route
• ça devrait aussi être normal que la fenêtre qui s'ouvre quand le programme est démarré (après tous les téléchargements de symboles depuis les servers MS) se ferme automatiquement en cas d'arrêt du programme. On va mettre un p'tit breakpoint sur exit pour calmer un peu tout ça;
• ne pas oublier le .exe à la fin du nom du programme. Faute de quoi, VS ne le trouvera pas et proposera juste un bouton 'Attach...' au lieu du bouton 'Start' !
  
• bon, par contre j'ai beau torturer ma ligne de commande, pas moyen de reproduire le crash dans cet environnement-là. Il va falloir trouver autre chose.
  

Et le plus agaçant, c'est que je sais que Windows peut le faire. Sur tant d'autres machines, il m'a saoûlé avec ses boîtes de dialogues ok/cancel/debug... ça pourrait être parce que Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug est vide, mais non: il me fait l'effet d'avoir bien tout ce qu'il faut là où il faut.

Ahmaisattends ... le programme de test mélange une bibliothèque C++ et du code compilé avec GHC, et le runtime haskell a un flag supplémentaire +RTS --generate-crash-dumps -RTS. On peut toujours essayer d'utiliser ça pendant notre debugging VS... Ah ? ... Bingo ?

On transfère bien son .pdb sur la machine de test ... Et voilà: j'ai un nom de fonction et un numéro de ligne. La méditation va pouvoir commencer.

Ah oui, il y a aussi le Windows Error Reporting (WER) system, et ses fichiers "planqués" dans C:\ProgramData\Microsoft\Windows. C'est ce qui ressemble le plus à mon ulimit. il faut créer la clé HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps et y définir "DumpType"=dword:00000002 (et plus si affinités. Attention, ça change le répertoire utiliser pour les dumps :-P)

Il y aura aussi procdump -e à tester, tiens.