Libelektra: fcrypt / gpgme / crypto: el caso de prueba falla

Parece que gpgme también se ve afectado:

 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 ¿ alguna idea?

para ser honesto, no. Los códigos de retorno no son documentos, pero podrían significar:

./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. */

No pude encontrar el significado de 256 hojeando el código.

Además, no puedo reproducir el problema localmente, como es habitual. :decepcionado:

¡Gracias por mirarlo!

La reproducción será bastante difícil, parece que solo ocurre esporádicamente y solo en la rama maestra ( @sanssecours o ¿lo vio también dentro de un PR?).

Quien imprime

OK closing connection

y

Terminating gpg-agent returned with status “256”

?

Vi esto esporádicamente mientras trabajaba en un PR. Desapareció después de la reconstrucción.

Creo que también lo vi en mis jenkins privados bajo una carga extremadamente alta. ¿Es posible que algo ocurra aquí?

¿Es posible que algo ocurra aquí?

¡Quizás! Dependiendo de la implementación de libassuan.

Actualización de estado: todavía no tengo idea de cómo solucionar este problema. ¡Cualquier idea es bienvenida!

¡Gracias por la actualizacion!

Creo que el camino a seguir es informar a la gente de GPG. Ya sabemos todo lo relevante, como el código de salida. Pero solo ellos pueden (si es que hay alguno) interpretar cómo puede ocurrir esto.

Si dicen: ohh, sí, este error a veces ocurre, debemos considerar que nuestros complementos ejecutan gpg nuevamente si ocurre este error.

Por cierto. No estoy seguro de si todavía hay apariciones de este problema. No los vi recientemente.

Por cierto. No estoy seguro de si todavía hay apariciones de este problema. No los vi recientemente.

Deshabilitamos testmod_fcrypt en el servidor de compilación de Jenkins .

Gracias por el recordatorio. ¿Y en los otros sistemas de compilación, el problema nunca ocurrió?

¿Y en los otros sistemas de compilación, el problema nunca ocurrió?

Podría haberlo hecho, pero de acuerdo con la descripción del problema # 2439 testmod_fcrypt solo falla regularmente en el servidor de compilación de Jenkins.

Si alguien nota un error, publíquelo aquí.

También observamos exactamente el mismo error causado por testmod_crypto en Debian Unstable durante el último PR (# 3395).

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

Volveré a escribir esta sección para usar execv con el fin de obtener una mejor comprensión de lo que está sucediendo en el servidor de compilación.

Si el error se repite, no dude en volver a abrir este problema.

El error volvió a ocurrir, todavía estoy investigando.

Por favor, envíeme un ping si el error se repite.

Pasó con gpgme de nuevo . (No sé si deberíamos abrir problemas separados para cada complemento o simplemente mantener este meta-problema)

 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.

No sé si deberíamos abrir problemas separados para cada complemento o simplemente mantener este meta-problema.

Creo que es el mismo (o muy similar) error relacionado con gpg. No creo que sea necesario abrir otro tema.

gpgme (o gpgme en combinación con valgrind) parece causar problemas si se redirecciona la salida de stdout y stderr.

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)

Supongo que esto explicaría por qué la salida de la prueba se escribe en los archivos de registro varias veces.

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

[truncated output]

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

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


gpgme Results: 45 Tests done — 0 errors.

¿Este problema está solucionado ahora?

@ petermax2 reescribió partes de las pruebas de cifrado y las movió a trabajos de CI separados ( debian-buster-cryptoplugins y debian-stretch-cryptoplugins ).

No he visto fallar estas pruebas desde esas mejoras. Creo que se puede cerrar de forma segura.

Me alegra saber que está funcionando ahora. ¡Gracias por los comentarios!