Danke für die Meldung, muss ich mir mal genauer anschauen.

Es tut mir sehr leid, dass ich so lange gebraucht habe , um zu danke Ihnen für Ihre Geduld.

Um die Dinge ein wenig zu verdeutlichen, sieht die relevante aktuelle db.c:db_col_db_add() so aus:

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

... Ich denke, die obige Version im ursprünglichen Problembericht war eine lokal gepatchte Kopie, um das Problem zu umgehen. Das Ändern des zurückgegebenen Fehlers hier klingt jedoch vernünftig; Wir haben EDOM zumindest in einigen anderen Arch/Endian-Codes verwendet, klingt das vernünftig für Sie?

Was denkst du @mheon?

Es sieht so aus, als ob wir wahrscheinlich auch db.c:db_col_merge() aktualisieren sollten, wenn wir schon dabei sind.

Aus API-Sicht halte ich es definitiv für sinnvoll, die Änderung vorzunehmen - das Überladen von Fehlercodes ist beim Debuggen immer problematisch.

Auf der libseccomp-golang-Seite sollte dies keine Codeänderungen erfordern, solange die negative ERRNO-Konvention beibehalten wird; vielleicht ein paar Zeilen Kommentare zu AddArch, um zu erklären, was der neue Fehler bedeutet, damit die API-Dokumentation vollständig ist.

Travis läuft noch einen zu alten Kernel, daher ist Test #47 erneut fehlgeschlagen. Wie @pcmoore vor einiger Zeit erwähnte, werde ich versuchen, dem Test einige Klugheit hinzuzufügen, um dies zu vermeiden.

Ansonsten sieht alles andere von dieser Änderung in meinem Buch gut aus

@drakenclimber Ich denke, du meinst Test 46, nicht 47, oder?

Vor ein paar Monaten habe ich den API-Level-Check für die Live-Tests hinzugefügt, aber ich glaube nicht, dass wir das für die bpf-sim-Tests brauchen, oder? Die BPF-SIM - Tests liefen sauber ...?

Travis hat definitiv bei Test #47 (KILL_PROCESS) für den obigen Lauf gekotzt. Ich habe heute morgen auch den gleichen Fehler beim HEAD des Masters gesehen, als ich ihn zur Überprüfung der Gesundheit in einen separaten Zweig verschoben habe.

Test 47-live-kill_process%%001-00001 Ergebnis: FAILURE 47-live-kill_process 3 KILL_PROCESS rc=12

Wir haben vor einiger Zeit darüber gesprochen, daher mag mein Gedächtnis trüb sein, aber ich dachte, Travis hätte Probleme mit dem KILL_PROCESS-Test, weil Travis' Kernel älter als 4.14 war, als diese Funktion eingeführt wurde.

Oder bin ich verrückt... und erinnere mich ganz falsch?

Hmm, sehen wir uns das gleiche Protokoll an? Ich schaue mir den Build und das Protokoll unten an:

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

... die folgende Ergebnisse zeigen (nur die "c"-Tests hier kopiert, die "Python"-Ergebnisse waren die gleichen):

 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)

... und ja, ältere Kernel haben ein Problem mit einigen Live-Tests, aber das hätte in 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730 behoben werden sollen.

FWIW, der letzte Travis-Build auf dem Master-Zweig lief sauber:

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

Ich habe gerade einen neuen Build mit dem Master-Zweig ausgelöst, um zu überprüfen, ob mit Travis alles "OK" ist:

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

Ich gebe zu, dass ich jetzt _wirklich_ verwirrt bin. Ihr Link zeigt definitiv, dass Test #46 das Problem ist. Aber wenn ich oben rechts auf den Link "Raw Log" klicke, wird mir mitgeteilt, dass #47 fehlgeschlagen ist. Für den Link, den Sie oben aufgelistet haben, wurde ich von Raw Log hierher weitergeleitet:

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

Wenn ich genauer hinschaue, denke ich, dass wir beide Recht haben.

46 gibt ERROR wie Sie bereits erwähnt haben. Und #47 gibt FAILURE (was ich ursprünglich gesucht hatte.)

Und das ist auch in den Zusammenfassungen sichtbar:

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

Ich kann die Probleme von TravisCI auf einem meiner Systeme reproduzieren, wenn ich in einen 3.x-Kernel boote. Test 46 hat am Ende Probleme in sys_chk_seccomp_action() . Dies führt letztendlich dazu, dass seccomp_init() einen NULL-Kontext an den Test zurückgibt.

Ich könnte mir vorstellen, dass die Probleme von Test 47 ähnlich sind, aber ich habe den Fehlerpfad nicht untersucht. (Obwohl die Änderung, die @pcmoore hinzugefügt hat, um die API zu überprüfen, dies hätte verhindern sollen. Hmmm ...)

Mich würde interessieren, was sich an Travis geändert hat, um dies zu verursachen. Sind sie auf einen wirklich alten Kernel zurückgefallen? Etwas von unserer Seite?

Es sieht so aus, als müssten wir den bpf-sim-Tests einige Tricks hinzufügen, um dies zu handhaben. Wollen wir die API-Spalte nachahmen, die der *.tests-Datei hinzugefügt wurde, oder etwas ganz anderes tun?

Ja, ich bin wirklich verwirrt, warum es funktioniert hat, da es jetzt nicht funktioniert. Ubuntu 14.xx ist heutzutage wirklich alt, ich werde sehen, ob es eine neuere Version auf Travis gibt.

Es sieht so aus, als ob Ubuntu 16.04 (Xenial) verfügbar ist, versuchen wir das ...

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 bringt uns auf Ubuntu 16.04. Ich mache das im Master-Zweig, nicht als PR, weil ich diesen Wechsel erzwingen möchte; Wenn der Build kaputt geht, werden wir es reparieren.

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

Dieser Build schien das Problem mit den Tests behoben zu haben, aber Clang hat gerade ein Speicherleck in einem Codepfad zur Fehlerbehandlung gefunden. Ich werde das in einer Minute beheben.

Fantastisch! Danke für die Hilfe, @pcmoore

Okay, mit Commit f8854f990004e71ccb9955c33d88d82cdb97ea42 sollten wir einen sauberen Gebäudemaster-Zweig haben. Es funktionierte gut in meinem persönlichen Zweig, der jetzt auf den Hauptbuild wartet.

@drakenclimber Ich sehe, dass Sie im

Dies sollte mit dem Commit 4a35b6ea6f7c836734536420c50a2745a9e24c69 behoben werden, der jetzt geschlossen wird. Wenn jemand ein Problem damit findet, öffnen Sie dieses Problem bitte erneut oder erstellen Sie ein neues.