Merci d'avoir signalé cela, je vais devoir regarder de plus près.

Je suis vraiment désolé qu'il m'ait fallu si longtemps pour revenir à ce @mvo5 , j'apprécie votre patience.

Pour clarifier un peu les choses, le db.c:db_col_db_add() actuel pertinent ressemble à ceci :

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

... Je pense que la version ci-dessus dans le rapport de problème d'origine était une copie corrigée localement pour contourner le problème. Cela dit, changer l'erreur renvoyée ici semble raisonnable ; nous avons utilisé EDOM dans au moins certains des autres codes arch/endian, cela vous semble-t-il raisonnable ?

Qu'en penses-tu @mheon ?

Il semble que nous devrions probablement également mettre à jour db.c:db_col_merge() pendant que nous y sommes.

Du point de vue de l'API, je pense vraiment qu'il est logique de faire le changement - la surcharge des codes d'erreur est toujours problématique pour le débogage.

Du côté de libseccomp-golang, cela ne devrait nécessiter aucun changement de code, tant que la convention ERRNO négative est maintenue ; peut-être quelques lignes de commentaires sur AddArch pour expliquer ce que signifie la nouvelle erreur, ainsi la documentation de l'API sera complète.

Travis exécute toujours un noyau trop ancien, donc le test #47 a de nouveau échoué. Comme @pcmoore l'a mentionné il y a quelque temps, je vais essayer d'ajouter quelques astuces au test pour éviter cela.

Sinon, tout le reste de ce changement a l'air bien dans mon livre

@drakenclimber Je pense que vous voulez dire le test 46, pas 47, non?

Il y a quelques mois, j'ai ajouté la vérification du niveau de l'API pour les tests en direct, mais je ne pense pas étaient en cours d' exécution propre ...?

Travis a définitivement vomi au test #47 (KILL_PROCESS) pour l'exécution ci-dessus. J'ai également vu le même échec sur le HEAD of master ce matin lorsque je l'ai poussé vers une branche distincte en tant que test de santé mentale.

Résultat du test 47-live-kill_process%%001-0001 : ÉCHEC 47-live-kill_process 3 KILL_PROCESS rc=12

Nous en avons parlé il y a un certain temps, donc ma mémoire est peut-être floue, mais je pensais que Travis avait des problèmes avec le test KILL_PROCESS parce que le noyau de Travis était plus ancien que 4.14 lorsque cette fonctionnalité a été introduite.

Ou suis-je fou... et me souviens-t-il complètement mal ?

Hmm, regardons-nous le même journal ? Je regarde la construction et le journal ci-dessous :

• https://travis-ci.org/drakenclimber/libseccomp/builds/488643921
• https://api.travis-ci.org/v3/job/488643923/log.txt

... qui montrent les résultats suivants (seulement copié les tests "c" ici, les résultats "python" étaient les mêmes):

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

... et oui, les noyaux plus anciens ont un problème avec certains des tests en direct, mais cela aurait dû être corrigé dans 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730.

FWIW, la dernière version de Travis sur la branche principale s'est déroulée correctement :

• https://travis-ci.org/seccomp/libseccomp/builds/431949896

Je viens de déclencher une nouvelle version en utilisant la branche master juste pour vérifier que tout est "OK" avec Travis :

• https://travis-ci.org/seccomp/libseccomp/jobs/488759868

J'admets que je suis maintenant _vraiment_ confus. Votre lien montre clairement que le test #46 est le problème. Mais lorsque je clique sur le lien "Raw Log" dans le coin supérieur droit, cela me dit que #47 a échoué. Pour le lien que vous avez indiqué ci-dessus, voici où le journal brut m'a redirigé :

• https://api.travis-ci.org/v3/job/488643923/log.txt

Alors en y regardant de plus près, je pense que nous avons tous les deux raison.

46 renvoie ERROR comme vous l'avez souligné. Et #47 renvoie FAILURE (ce que j'avais recherché à l'origine.)

Et cela se voit aussi dans les résumés :

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0

Je suis capable de reproduire les problèmes de TravisCI sur l'un de mes systèmes si je démarre dans un noyau 3.x. Le test 46 finit par avoir des problèmes dans sys_chk_seccomp_action() . Cela amène finalement seccomp_init() à renvoyer un contexte NULL au test.

J'imagine que les problèmes du test 47 sont similaires, mais je n'ai pas enquêté sur son chemin d'échec. (Bien que le changement @pcmoore ajouté pour vérifier l'API aurait dû empêcher cela. Hmmm...)

Je serais curieux de savoir ce qui a changé sur Travis pour provoquer cela. Sont-ils retombés dans un noyau vraiment ancien ? Quelque chose de notre côté ?

Il semble que nous devrons ajouter des éléments intelligents aux tests bpf-sim pour gérer cela. Voulons-nous imiter la colonne API ajoutée au fichier *.tests ou faire autre chose ?

Ouais, je suis vraiment confus quant à pourquoi cela fonctionnait comme maintenant ce n'est pas le cas. Ubuntu 14.xx est vraiment vieux ces jours-ci, je vais voir s'il existe une version plus récente disponible sur Travis.

Il semble qu'Ubuntu 16.04 (Xenial) soit disponible, essayons ça ...

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 nous fait passer à Ubuntu 16.04. Je le fais dans la branche master, pas en tant que PR, car je veux forcer ce changement ; si la construction tombe en panne, nous le réparerons.

• https://travis-ci.org/seccomp/libseccomp/builds/489230929

Cette version semblait avoir résolu le problème avec les tests, mais clang vient de trouver une fuite de mémoire dans un chemin de code de gestion des erreurs. Je vais régler ça dans une minute.

Impressionnant! Merci pour l'aide, @pcmoore

D'accord, avec commit f8854f990004e71ccb9955c33d88d82cdb97ea42, nous devrions avoir une branche master de construction propre. Cela a bien fonctionné sur ma branche personnelle, en attendant la version principale maintenant.

@drakenclimber Je vois que vous avez un correctif prêt pour cela dans le journal des problèmes ci-dessus, mais je ne vois pas encore de PR - êtes-vous toujours à la recherche de problèmes avec le correctif ou est-il prêt pour un PR ?

Cela devrait être résolu avec le commit 4a35b6ea6f7c836734536420c50a2745a9e24c69, en le fermant maintenant. Si quelqu'un rencontre un problème avec cela, veuillez rouvrir ce problème ou en créer un nouveau.