Forum Programmation.autre Erreur de segmentation passe inaperçu dans une recette GNU Make

Posté par  . Licence CC By‑SA.
Étiquettes :
3
4
déc.
2021

Bonjour.

Je suis sous Manjaro. J'ai écrit un Makefile pour tester à la chaîne une série de programmes en C, dont la construction (mais ce n'est pas le sujet, c'est juste le contexte) et un de ces programmes se termine avec une erreur de segmentation. Le seul souci c'est que je ne la vois pas en exécutant le Makefile mais uniquement lorsque j'exécute le programme à la main.

La cible est constituée comme suit:

test: main
    # Tester avec des données erronées, recommencer avec des données correctes en cas d'erreur
    @printf "bla bla bla" | ./$<

Le programme à (construire et) tester est main et je lance la commande make test, rien de plus. J'ai essayé en rendant la commande non-silencieuse dans la recette mais ça ne change rien. J'ai aussi essayé avec le suffixe "2>&1" ou "&>", pareil. Comment puis-je forcer make à afficher le message d'erreur?

Merci d'avance pour tout aide ou suggestion.

P.S.: J'ajoute que ça fait deux jours que je cherche sur internet et je n'ai rien trouvé.

  • # C'est l'histoire d'un make...

    Posté par  . Évalué à 5.

    Oui je rigole tout seul de mes propres blagues.
    Bon, je ne sait pas si cela va faire avancé le schmilblick mais as tu essayé de lancer make en mode verbose ?
    En faisant "make test --debug=v" ou si as le temps de faire de la lecture --debug=a

    • [^] # Re: C'est l'histoire d'un make...

      Posté par  . Évalué à 3.

      Oui je rigole tout seul de mes propres blagues.

      Tracasse, j'adore celle-là !

      En faisant "make test --debug=v" ou si as le temps de faire de la lecture --debug=a

      Ça ne fonctionne effectivement pas mais j'ai trouvé une solution dans la réponse de gUI. Merci pour tes suggestions.

  • # Je crois que c'est normal en fait

    Posté par  (Mastodon) . Évalué à 6. Dernière modification le 04 décembre 2021 à 11:25.

    Je me suis dit "mais keskiraconte çuila", j'ai fait 3 bouts de C et un Makefile… et j'ai évidemment la même chose.

    En cherchant un peu et en compilant les trouvailles (merci Stackoverflow encore une fois), j'ai trouvé les indices suivants :
    - make te dis qqchoe comme 'error 139', ça veut dire que la commande exécutée est en segfault. donc ton info tu l'as.
    - l'affichage que tu cherches c'est pas l'exécutable qui le fait, c'est celui qui l'a lancé. donc tu le vois avec ton bash, mais pas avec Makefile (qui te dit 'error 139'). les redirections n'y feront rien.

    Donc faut faire avec :)

    https://stackoverflow.com/questions/26168138/makefile-ignore-segfault
    https://stackoverflow.com/questions/32564735/what-actually-prints-segmentation-fault

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Je crois que c'est normal en fait

      Posté par  . Évalué à 2.

      Je me suis dit "mais keskiraconte çuila", j'ai fait 3 bouts de C et un Makefile… et j'ai évidemment la même chose.

      Aaah, je me disais bien, je ne suis pas fou!

      La question 26168138 sur SO part d'une personne qui souhaite cache le message d'erreur SEGFAULT. Je l'ai lu celui-là aussi mais ça ne m'a pas apporté de réponse.

      En revanche, là tu m'intéresses:

      make te dis qqchoe comme 'error 139', ça veut dire que la commande exécutée est en segfault. donc ton info tu l'as.

      Et en effet; je viens de modifier ma ligne de recette pour récupérer et afficher le code de sortie de l'exécutable. Maintenant que je sais que 139 c'est 128+SIGSEGV, je nage dans le bonheur. Alors merci!

      Maintenant il ne me reste qu'à écrire ce qu'il faut pour traduire les codes de retour en un texte clair. Mais ça je trouverai.

      • [^] # Re: Je crois que c'est normal en fait

        Posté par  (Mastodon) . Évalué à 3.

        Je l'ai lu celui-là aussi mais ça ne m'a pas apporté de réponse.

        Et bien il m'a mis la puce à l'oreille : lui il l'a le message segfault coredump. Pourquoi donc ???

        Et si tu regardes, il y a /bin/sh : il doit lancer des scipts (et pas un exécutable directement) et du coup il a le message. De plus il y a l'erreur 139… comme moi !

        Bref en recoupant et en cherchant qui imprime ce truc, j'ai pu confirmer.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Avoir une logique complexe dans un makefile…

    Posté par  (site web personnel) . Évalué à 3.

    Le premier problème c'est surtout que tu utilises make avec une logique complexe… avec pour seule bonne raison (je suppose) que tu as déjà un Makefile qui construit ton projet et fait un peu de tout et n'importe quoi à côté.

    Alors oui bien-sûr c'est possible de faire cela… mais est-ce souhaitable?

    À choisir, écrire des scripts shell c'est quand-même plus facile que d'écrire des Makefiles, donc je ne peux que te recommander de mettre ton programme qui lance tes tests dans un script shell, quitte à appeler ce script dans ton makefile si tu aimes bien taper make test par exemple où juste que tu ne veux pas changer ton habitude.

    L'intérêt de mettre tes commandes dans un script shell est que ça te dispense de savoir beaucoup des petits détails du fonctionnement de make et que tu peux écrire plus facilement ta procédure de test, par exemple en utilisant des fonctions, etc.

    Make te permet d'écrire assez facilement des programmes dont l'état est encodé dans le système de fichiers, en te donnant presque gratuitement le parallélisme d'éxécution et la possibilité de récupérer les erreurs (je recompile juste ce qu'il faut après avoir corrigé). Je pense que bien garder cela en tête permet de savoir si on a intérêt à déléguer à un shell script, la question clé étant: est-ce que l'état de ma tâche est défini par le système de fichier?

    • [^] # Re: Avoir une logique complexe dans un makefile…

      Posté par  . Évalué à 3.

      Merci pour la suggestion. Parfois on a en effet besoin de remettre en question le choix technique de départ car on peut très bien se fourvoyer à un moment ou un autre et se perdre à suivre le lapin blanc. Ce que tu proposes est sage en effet. Cependant je ne suis pas certain de partage l'argument "logique complexe" car le problème que je rencontre ici est la versatilité de make quant à l'affichage d'un message d'erreur de type "erreur de segmentation": dans certains cas, il l'affiche et dans d'autres non, va-t'en savoir pourquoi…

      J'imagine que c'est le thème de ton argumentation: utiliser un moyen moins prise de tête qui ferait le tout de manière plus simple au lieu de se casser le tronc avec make. C'est ça?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.