Libelektra: fcrypt / gpgme / crypto : le cas de test échoue

Il semble que gpgme soit également affecté :

 62/137 MemCheck #103: testmod_gpgme ....................***Failed   44.22 sec

GPGME        TESTS

==================

[repetitions cut]


GPGME        TESTS

==================


OK closing connection

Terminating gpg-agent returned with status “256”GPGME        TESTS

==================


/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:227: error in test_encryption_decryption: kdb get failed

/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:243: error in test_encryption_decryption: key type not restored to string during decryption

/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:244: error in test_encryption_decryption: key content not restored during decryption

/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:254: error in test_encryption_decryption: key content not restored during decryption


gpgme Results: 45 Tests done — 4 errors.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/34/pipeline

@ petermax2 une idée ?

pour être honnête, non. Les codes retour ne sont pas des documents, mais ils peuvent signifier :

./src/gpg-error.h.in:968:#define GPGRT_LOG_RUN_DETACHED 256
./src/gpg-error.h.in:1175:#define ARGPARSE_FLAG_STOP_SEEN 256  /* Set to true if a "--" has been seen. */

Je n'ai pas pu trouver la signification de 256 en parcourant le code.

Aussi je ne peux pas reproduire le problème localement, comme d'habitude. :désappointé:

Merci d'avoir jeté un coup d'œil!

Reproduire sera assez difficile, cela ne semble se produire que sporadiquement et uniquement sur la branche master ( @sanssecours ou l'avez-vous vu aussi au sein d'un PR ?).

Qui imprime

OK closing connection

et

Terminating gpg-agent returned with status “256”

?

J'ai vu cela sporadiquement en travaillant sur un PR. Il a disparu après la reconstruction.

Je pense que je l'ai aussi vu sur mes jenkins privés sous une charge extrêmement élevée. Est-il possible que quelque chose se termine ici ?

Est-il possible que quelque chose se termine ici ?

Peut-être! Selon la mise en œuvre de libassuan.

Mise à jour du statut : je n'ai toujours aucune idée de comment résoudre ce problème. Toutes les idées sont les bienvenues !

Merci pour la mise à jour!

Je pense que la voie à suivre est de le signaler aux gens de GPG. Nous savons déjà tout ce qui est pertinent, comme le code de sortie. Mais eux seuls peuvent (le cas échéant) interpréter comment cela peut se produire.

S'ils disent : ohh, oui, cette erreur se produit parfois, nous devons considérer que nos plugins exécutent à nouveau gpg si cette erreur se produit.

D'ailleurs. Je ne sais pas s'il y a encore des occurrences de ce problème. Je ne les ai pas vus récemment.

D'ailleurs. Je ne sais pas s'il y a encore des occurrences de ce problème. Je ne les ai pas vus récemment.

Nous avons désactivé testmod_fcrypt sur le serveur de build Jenkins .

Merci pour le rappel. Et sur les autres systèmes de build, le problème ne s'est jamais produit ?

Et sur les autres systèmes de build, le problème ne s'est jamais produit ?

C'est peut-être le cas, mais selon la description du problème #2439 testmod_fcrypt échoue régulièrement sur le serveur de build Jenkins.

Si quelqu'un remarque un échec, veuillez le poster ici.

Nous avons également observé exactement la même erreur causée par testmod_crypto sur Debian Unstable lors de la dernière PR (#3395 ).

https://github.com/ElektraInitiative/libelektra/blob/2e6a5795fde79158f3102c04859dc1091a9dc1d8/src/plugins/crypto/gpgagent_teardown.h#L15

Je vais réécrire cette section pour utiliser execv afin de mieux comprendre ce qui se passe sur le serveur de build.

Si l'erreur se reproduit, n'hésitez pas à rouvrir ce problème.

L'erreur s'est à nouveau produite, je suis toujours en train de chercher.

Veuillez me faire un ping si l'erreur se reproduit.

C'est encore arrivé avec gpgme . (Je ne sais pas si nous devrions ouvrir des problèmes séparés pour chaque plugin ou simplement garder ce méta-problème ?)

 80/137 MemCheck  #87: testmod_gpgme ....................***Failed   43.49 sec

GPGME        TESTS

==================

[... mpranj truncated a little bit here ...]

GPGME        TESTS

==================



/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:227: error in test_encryption_decryption: kdb get failed

/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:243: error in test_encryption_decryption: key type not restored to string during decryption

/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:244: error in test_encryption_decryption: key content not restored during decryption

/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:254: error in test_encryption_decryption: key content not restored during decryption



gpgme Results: 45 Tests done — 4 errors.

Je ne sais pas si nous devrions ouvrir des problèmes séparés pour chaque plugin ou simplement garder ce méta-problème ?

Je pense que c'est la même erreur (ou très similaire) liée à gpg. Je ne pense pas qu'il soit nécessaire d'ouvrir un autre sujet.

gpgme (ou gpgme en combinaison avec valgrind) semble poser des problèmes si la sortie de stdout et stderr est redirigée.

GPGME        TESTS
==================

==155492== Warning: invalid file descriptor 1012 in syscall close()
==155492== Warning: invalid file descriptor 1013 in syscall close()
==155492== Warning: invalid file descriptor 1014 in syscall close()
==155492== Warning: invalid file descriptor 1015 in syscall close()
==155492==    Use --log-fd=<number> to select an alternative log fd.
==155492== Warning: invalid file descriptor 1016 in syscall close()
==155492== Warning: invalid file descriptor 1017 in syscall close()
==155492== Warning: invalid file descriptor 1018 in syscall close()
==155491== 
==155491== HEAP SUMMARY:
==155491==     in use at exit: 25,235 bytes in 176 blocks
==155491==   total heap usage: 802 allocs, 626 frees, 119,751 bytes allocated
==155491== 
==155491== LEAK SUMMARY:
==155491==    definitely lost: 0 bytes in 0 blocks
==155491==    indirectly lost: 0 bytes in 0 blocks
==155491==      possibly lost: 0 bytes in 0 blocks
==155491==    still reachable: 23,146 bytes in 163 blocks
==155491==         suppressed: 2,089 bytes in 13 blocks
==155491== Reachable blocks (those to which a pointer was found) are not shown.
==155491== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==155491== 
==155491== For counts of detected and suppressed errors, rerun with: -v
==155491== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
GPGME        TESTS
==================


gpgme Results: 45 Tests done — 0 errors.
==155462== 
==155462== HEAP SUMMARY:
==155462==     in use at exit: 4,833 bytes in 39 blocks
==155462==   total heap usage: 955 allocs, 916 frees, 698,713 bytes allocated
==155462== 
==155462== LEAK SUMMARY:
==155462==    definitely lost: 0 bytes in 0 blocks
==155462==    indirectly lost: 0 bytes in 0 blocks
==155462==      possibly lost: 0 bytes in 0 blocks
==155462==    still reachable: 3,241 bytes in 35 blocks
==155462==         suppressed: 1,592 bytes in 4 blocks
==155462== Reachable blocks (those to which a pointer was found) are not shown.
==155462== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==155462== 
==155462== For counts of detected and suppressed errors, rerun with: -v
==155462== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Je suppose que cela expliquerait pourquoi la sortie du test est écrite plusieurs fois dans les fichiers journaux.

GPGME        TESTS
==================

[truncated output]

GPGME        TESTS
==================

GPGME        TESTS
==================


gpgme Results: 45 Tests done — 0 errors.

Ce problème est-il résolu maintenant ?

@petermax2 a réécrit des parties des tests cryptographiques et les a déplacés vers des tâches CI distinctes ( debian-buster-cryptoplugins et debian-stretch-cryptoplugins ).

Je n'ai pas vu ces tests échouer depuis ces améliorations. Je pense qu'il peut être fermé en toute sécurité.

Heureux d'entendre que cela fonctionne maintenant. Merci pour votre retour!