Der specload -Testfehler ist ziemlich eindeutig:

reason: : App '/home/jenkins/workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA/libelektra/obj-x86_64-linux-gnu/bin/elektra-specload-testapp' doesn't exist or is not executable

Bei quickdump kann ich nicht genau sagen, was falsch ist, aber es scheitert irgendwo in elektraQuickdumpSet . Es sollte ein Fehler in setKey gesetzt sein, aber er wird meiner Meinung nach nicht protokolliert (das sollte wahrscheinlich geändert werden).

Keine Ahnung, warum gopts fehlschlägt. Da keine Fehlermeldung gedruckt wurde, vermute ich, dass die Testapp elektra-gopts-testapp nicht ausgeführt werden konnte (es ist der einzige Fall, in dem keine Fehlermeldung gedruckt würde). Es würde auch mit dem Fehler specload übereinstimmen.

Der Specload-Testfehler ist ziemlich eindeutig:

Ja, aber es ist falsch, Binärdateien im Build-Verzeichnis zu erwarten, nachdem die Anwendung installiert wurde. Die Binärdateien sollten entweder im Build- oder im Installationsverzeichnis installiert und durchsucht werden.

Der Specload-Testfehler ist ziemlich eindeutig:

Ja, aber es ist falsch, Binärdateien im Build-Verzeichnis zu erwarten, nachdem die Anwendung installiert wurde. Die Binärdateien sollten entweder im Build- oder im Installationsverzeichnis installiert und durchsucht werden.

Oh, ich habe übersehen, dass du Elektra installiert hast. Das erklärt jedoch nicht den Fehler quickdump , seine Testdaten sind korrekt installiert.

Ich bin mir auch nicht sicher, wie ich dieses Problem lösen soll. Natürlich können wir die ausführbaren Dateien der Test-Apps installieren, aber die eigentlichen ausführbaren Testdateien müssten während der Installation geändert werden, um zu ändern, wo sie nach der Test-App suchen.

Es ist zu viel Arbeit, nach den Binärdateien zu suchen (entweder im Build- oder Installed-Verzeichnis), wir können die Tests auch von der Installation ausschließen.

Wir könnten einfach einen relativen Pfad verwenden und sicherstellen, dass er während der Installation gleich bleibt, z. B. beide Binärdateien im selben Verzeichnis haben.

Ja, gute Idee.

Eine allgemeinere Lösung wäre, wenn wir kdb <command> auch im Build-Verzeichnis verfügbar haben (funktioniert derzeit nur, wenn Elektra installiert ist). Es wäre ziemlich viel Arbeit, da KDB_EXEC_PATH nur einen Pfad unterstützt, aber die Binärdateien in vielen verschiedenen Teilen des Build-Verzeichnisses verstreut sind.

Wir haben KDBauch im Build-Verzeichnis verfügbar

Tests können einfach über ctest und/oder make ausgeführt werden. Was die anderen Befehle betrifft, machen die meisten sowieso nur Sinn für eine installierte Version von Elektra.

Wir könnten einfach einen relativen Pfad verwenden und sicherstellen, dass er während der Installation gleich bleibt, z. B. beide Binärdateien im selben Verzeichnis haben.

Es stellt sich heraus, dass dies schwieriger ist als erwartet. Die stdlib würde den relativen Pfad relativ zum aktuellen Arbeitsverzeichnis behandeln, was nicht hilfreich ist, und das Auflösen des Pfads relativ zum Pfad der aktuellen ausführbaren Datei ist nicht plattformunabhängig möglich.

Daher wäre der kdb <command> -Weg ziemlich attraktiv.

Für die Installation reicht es aus, es in TARGET_TOOL_EXEC_FOLDER zu installieren

Nur während der Build-Zeit brauchen wir eine Möglichkeit, build_dir/bin build_dir/scripts source_dir/scripts und die aktuellen Verzeichnisse (vielleicht auch build+source) zu kombinieren.

@kodebach ist das noch offen? Können wir viele diese Situation erkennen und die Tests in dieser Situation nicht laufen lassen?

Oder wir beheben es: KDB_EXEC_PATH erlaubt jetzt mehrere Pfade, sodass wir alle benötigten Ordner aus dem Build/Source-Verzeichnis hinzufügen können. Dann lassen Sie einfach kdb die Aufgabe erledigen, die ausführbare Datei zu finden.

AFAIK ist das noch offen, ja.

Wir haben bereits die Funktion srcdir_file für Tests. Wir könnten ein ähnliches bindir_file einführen. bindir wäre standardmäßig ${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} , aber es gäbe eine Möglichkeit, es zu überschreiben. CTest würde (über add_test CMake) so eingerichtet, dass bindir auf ${CMAKE_BINARY_DIR}/bin gesetzt wird, wenn ctest verwendet wird.

Und das einfache Hinzufügen des Bindir zu KDB_EXEC_PATH und die Verwendung kdb <bin> funktioniert nicht?

Nein, aus mehreren Gründen:

1. Dies sind testmod_ Tests, sie sollten sich nicht auf kdb verlassen.
2. Wie würden wir dann kdb finden? Das Ausführen von Tests mit make run_all sollte nicht das installierte kdb verwenden, sondern das in ${CMAKE_BINARY_DIR}/bin .
3. KDB_EXEC_PATH würde nach der Installation kdb immer noch den Ordner ${CMAKE_BINARY_DIR}/bin #$ enthalten, was verschiedene Probleme verursachen könnte.

Dies sind testmod_ Tests, sie sollten sich nicht auf kdb verlassen.

Ja, ich stimme zu. Es ist gut, wenn sie eigenständig arbeiten.

Wie würden wir dann kdb finden? Das Ausführen von Tests mit make run_all sollte nicht die installierte kdb verwenden, sondern die in ${CMAKE_BINARY_DIR}/bin.

Shellrecorder-Tests verwenden bereits kdb, und sie funktionieren sowohl für installiertes Elektra als auch aus dem Build-Verzeichnis (selbst wenn Elektra installiert ist).

KDB_EXEC_PATH würde nach der Installation von kdb immer noch den Ordner ${CMAKE_BINARY_DIR}/bin enthalten, was verschiedene Probleme verursachen könnte.

Nein, KDB_EXEC_PATH ist nicht für eine installierte kdb gesetzt (es sei denn, der Benutzer legt es fest)

Shellrecorder-Tests verwenden bereits kdb, und sie funktionieren sowohl für installiertes Elektra als auch aus dem Build-Verzeichnis (selbst wenn Elektra installiert ist).

Das funktioniert, weil Shell-Tests immer "$KDB" und niemals kdb ausführen. Und auch, weil make run_all und ctest zB testscr_check_meta.sh Skripte verwenden, während kdb zB check_meta.sh verwendet. Im ersten setzen wir $KDB auf ${CMAKE_BINARY_DIR}/bin/kdb im zweiten wird es einfach auf kdb gesetzt (und daher über $PATH aufgelöst).

Nein, KDB_EXEC_PATH ist nicht für eine installierte kdb gesetzt (es sei denn, der Benutzer legt es fest)

Ich habe einfach die Master-Version von Elektra genommen und installiert. Die Datei /usr/local/lib/elektra/tool_exec/check_meta enthält die Zeile:

export KDB_EXEC_PATH="/home/klemens/libelektra/build/bin:$KDB_EXEC_PATH"

Das betrifft natürlich nicht testmod_* Tests, ist aber trotzdem falsch. Ich werde ein neues Thema erstellen.

@petermax2 @kodebach wie ist der Stand dieses Problems? Ist #3246 jetzt behoben (über #3409), ist der Rest dieses Problems nur Verpackungsprobleme oder muss noch etwas implementiert werden?

AFAIK, das ursprüngliche Problem mit specload existiert immer noch. TBH Ich bin mir nicht sicher, warum wir überhaupt testmod_ Tests installieren müssen. Das macht keinen Sinn. Dies sind eigenständige Tests, die ein einzelnes Plugin isoliert testen. Wenn sie tatsächlich ausgeführt werden, sind ihre Ergebnisse gleich, unabhängig davon, ob sie im Build-Verzeichnis oder im Installationsverzeichnis ausgeführt werden.

TBH Ich bin mir nicht sicher, warum wir überhaupt die Option haben müssen, testmod_ tests zu installieren.

Im Moment haben wir keine Option, um die Installation von Tests zu deaktivieren, aber wir könnten eine lokale Überschreibung vornehmen, damit add_plugintest keine Tests installiert (wie INSTALL_TESTING, aber für einzelne add_plugintest ).

Das macht keinen Sinn. Dies sind eigenständige Tests, die ein einzelnes Plugin isoliert testen. Wenn sie tatsächlich ausgeführt werden, sind ihre Ergebnisse gleich, unabhängig davon, ob sie im Build-Verzeichnis oder im Installationsverzeichnis ausgeführt werden.

:wink:, es gibt viele Unterschiede, aber die meisten betrafen das Plugin-System selbst (sie sind hoffentlich inzwischen alle behoben). Dennoch gibt es eine große Bandbreite möglicher Abhängigkeitsprobleme und Installationsprobleme, sodass es viel besser ist, die Testmod-Tests im installierten Zustand auszuführen, als nichts auszuführen. Aber Sie haben Recht, wenn es einen Shellrecorder-Test gibt, ist der Testmod-Test nutzlos.

• [X] Also für Quickdump ist klar, der Testmod Test muss nicht installiert werden.
• [ ] Für Specload gibt es einen Test, aber es scheint ziemlich minimal zu sein, vielleicht okay, aber besser, Sie überprüfen es noch einmal.
• [ ] Für gopts könnten wir Beispielprogramme in doc/tutorials/command-line-options.md laufen lassen?

@kodebach kannst du prüfen, ob diese Tests sicher ausgeschlossen werden können?

@robaerd kannst du sie in einem deiner CI PRs ausschließen? (Vor oder wo Sie das Testen von Paketen hinzufügen.)

@markus2330 Tritt das Quickdump-Problem bei dir immer noch auf? AFAIK, wir haben nie herausgefunden, was dort falsch war. Ich konnte es auch nicht reproduzieren.

Für gopts und specload siehe #3618

Ja, kommt noch vor:

kdb testmod_quickdump                                                                                                                                                                                                                    
QUICKDUMP     TESTS
==================

test varint
test basics
/home/jenkins/workspace/libelektra_master/libelektra/src/plugins/quickdump/testmod_quickdump.c:111: error in test_basics: call to kdbSet was not successful
zsh: segmentation fault (core dumped)  noglob kdb testmod_quickdump

Oder wenn ich es von der Quelle aus anrufe:

„QUICKDUMP-TESTS

Testvariante
Grundlagen testen
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:92: Fehler in test_basics: Aufruf von kdbGet war nicht erfolgreich
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: error in test_basics: real size of mmks2 was 0
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: error in test_basics: Compare keyset failed, size of keysets are not equal with size(mmks1): 8, size(mmks2): 0
mmks1:
0x55a9efd438d0 Schlüssel: dir:/tests/bench/__112, Zeichenfolge: gQHLlzb36CqIFlf, meta:/meta/_35: O6xNya6srhNhMFC, meta:/meta/_39: ublVuvyh1DgfOKU, meta:/meta/_58: 5Nyde2MHJODCBAT, meta:/meta/_79: ZK2xlaRMfobquxp, meta:/meta/_90: 0kCcc1pK7hOgY3F
0x55a9efd44250 Schlüssel: dir:/tests/bench/__114, Zeichenfolge: , meta:/binary:
0x55a9efd441a0 Schlüssel: dir:/tests/bench/__333, Zeichenfolge: SxTUAjM6OIpUV6s
0x55a9efd440f0 Schlüssel: dir:/tests/bench/__506, Zeichenfolge: cGqEvmXxUayNCf8
0x55a9efd44040 Schlüssel: dir:/tests/bench/__859, Zeichenfolge: rOI5aVFGlnjPLYJ
0x55a9efd43f90 Schlüssel: dir:/tests/bench/__863, Zeichenfolge: 8IBjbd5pzYBehrs
0x55a9efd43f20 Schlüssel: dir:/tests/bench/__868, Zeichenfolge: UVM0OPTf68yNXij
0x55a9efd43d90 Schlüssel: dir:/tests/bench/__911, Zeichenfolge: PgNbwPxfeqD30pH, meta:/meta/_35: O6xNya6srhNhMFC
mmks2:
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:111: Fehler in test_basics: Aufruf von kdbSet war nicht erfolgreich
zsh: Segmentierungsfehler (Core Dump) LD_LIBRARY_PATH=lib bin/testmod_quickdump

Stacktrace:

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) bei getc.c:37

1 0x000055a9ede54c58 in „compare_binary_files“ (Dateiname2=0x55a9efd42a30 „/usr/local/share/elektra/test_data/quickdump/test.quickdump.out“, Dateiname1=0x55a9efd429e0 „/usr/local/share/elektra/test_data/quickdump/test.quickdump“ )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics () unter /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 0x000055a9ede545d7 in main (argc=1, argv=0x7ffff28085f8) unter /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) bei getc.c:37

37 getc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) bei getc.c:37

1 0x000055a9ede54c58 in „compare_binary_files“ (Dateiname2=0x55a9efd42a30 „/usr/local/share/elektra/test_data/quickdump/test.quickdump.out“, Dateiname1=0x55a9efd429e0 „/usr/local/share/elektra/test_data/quickdump/test.quickdump“ )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics () unter /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 0x000055a9ede545d7 in main (argc=1, argv=0x7ffff28085f8) unter /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278

(gdb) bt voll

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) bei getc.c:37

    result = <optimized out>

1 0x000055a9ede54c58 in „compare_binary_files“ (Dateiname2=0x55a9efd42a30 „/usr/local/share/elektra/test_data/quickdump/test.quickdump.out“, Dateiname1=0x55a9efd429e0 „/usr/local/share/elektra/test_data/quickdump/test.quickdump“ )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31
    f2 = 0x0
    c1 = <optimized out>
    f1 = 0x0
    result = 0
    c2 = <optimized out>
    f1 = <optimized out>
    f2 = <optimized out>
    result = <optimized out>
    c1 = <optimized out>
    c2 = <optimized out>
    end1 = <optimized out>
    end2 = <optimized out>

2 test_basics () unter /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

    conf = <optimized out>
    modules = 0x55a9efd43a00
    setKey = 0x55a9efd42bb0
    errorKey = <optimized out>
    plugin = 0x55a9efd43b00
    ks = <optimized out>
    infile = 0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump"
    outfile = 0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out"
    __func__ = "test_basics"

3 0x000055a9ede545d7 in main (argc=1, argv=0x7ffff28085f8) unter /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:27

```

Oder wenn ich es von der Quelle aus anrufe:

Wenn Sie Tests direkt ausführen, verwenden Sie bitte ctest (z. B. ctest -R testmod_quickdump --ouptut-on-failure ), um sicherzustellen, dass Umgebung, Argumente usw. korrekt eingestellt sind.

In diesem Fall denke ich, dass LD_LIBRARY_PATH=lib bin/testmod_quickdump ../src/plugins/quickdump das ist, was Sie brauchen (wenn Sie zB mit gdb debuggen möchten).

Existiert /usr/local/share/elektra/test_data/quickdump/test.quickdump auf Ihrem System und hat der Prozess Schreibrechte auf /usr/local/share/elektra/test_data/quickdump/test.quickdump.out ? (Vielleicht brauchen Sie sudo kdb testmod_quickdump )

Wenn ja, bitte hinzufügen

output_error (setKey);
output_warnings (setKey);

in testmod_quickdump.c:112 und poste die Ausgabe.

elektraQuickdumpSet ist fehlgeschlagen, daher ist die Tatsache, dass compare_binary_files fehlschlägt, völlig zu erwarten. (Die Fehlermeldung könnte natürlich besser sein und der Segfault könnte vermieden werden, aber es ist ein _fehlgeschlagener_ Test, also spielt es keine so große Rolle)

Ja, das Problem ist, dass die Testfälle versuchen, temporäre Dateien in einem dafür nicht geeigneten Ordner zu erstellen. sudo kdb testmod_quickdump läuft ohne Probleme. Es sollte also ausreichen, unsere Funktionen zum Erstellen temporärer Dateien zu verwenden, anstatt "test_data/quickdump/test.quickdump.out" zu verwenden.

Wir können das ändern, ja, aber viele Tests laufen sowieso nicht ohne sudo , also sehe ich das nicht wirklich als Problem

Von welchen Tests sprichst du? Ich führe die gesamte Suite immer ohne sudo aus (aber mit Schreibrechten auf Elektras Pfad). testmod_quickdump ist afaik der einzige Test mit diesem Problem.

aber mit Schreibrechten auf Elektras Pfad

Okay, das funktioniert auch, aber auf einem Standardsystem sind diese Pfade nur Root-Zugriff.

Ich denke immer noch, dass das ganze Konzept der Ausführung von Komponententests in einer installierten Version von Elektra seltsam ist, und das Quickdump-Problem ist ein reines Problem mit den Benutzerrechten, kein Fehler, aber ich werde den Pfad in #3618 ändern.

Ich habe jetzt den Code in #3618 aktualisiert. Ich habe auch ähnlichen Code in testmod_dump gefunden und das war gut geändert. Keine Ahnung, warum das bei dir nicht gescheitert ist. testmod_xmltool könnte ein ähnliches Problem haben (obwohl der Code anders ist, also habe ich ihn nicht geändert).

testmod_quickdump war nur einer von denen, die Binärdateien verwendeten und daher compare_line_files nicht verwendeten. Daher würden die anderen keinen Segfault durchführen, aber die Tests sollten trotzdem fehlschlagen.

Und das Quickdump-Problem ist ein reines Problem mit den Benutzerrechten, kein Fehler,

Es ist eine Verletzung von FHS, Anwendungen sollten nicht in /usr schreiben, es könnte sogar schreibgeschützt sein.

Zum Schreiben sollten wir nur Tempfiles verwenden und diese nach Abschluss der Tests auch bereinigen.