Libelektra: fcrypt / gpgme / crypto: test case fails

Seems like gpgme is also affected:

 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 any idea?

to be honest, no. The return codes are not documentes, but they could mean:

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

I could not find the meaning of 256 by skimming through the code.

Also I can not reproduce the problem locally, as usual. :disappointed:

Thank you for taking a look!

Reproducing will be rather difficult, it seems to only occur sporadically and only on the master branch (@sanssecours or did you see it also within a PR?).

Who prints

OK closing connection

and

Terminating gpg-agent returned with status “256”

?

I saw this sporadically while working on a PR. It vanished after rebuilding.

I think I also saw it on my private jenkins under extremely high load. Is it at all possible that something times out here?

Is it at all possible that something times out here?

Maybe! Depending on the implementation of libassuan.

Status update: I still have no idea how to overcome this issue. Any ideas are welcome!

Thank you for the update!

I think the way forward is to report it to the GPG people. We already know everything relevant, like the exit code. But only they can (if anyone) interpret how this can occur.

If they say: ohh, yes, this error sometimes occurs, we should consider that our plugins run gpg again if this error happens.

Btw. I am not sure if there are still occurrences of this problem. I did not see them recently.

Btw. I am not sure if there are still occurrences of this problem. I did not see them recently.

We disabled testmod_fcrypt on the Jenkins build server.

Thank you for the reminder. And on the other build systems the problem never occurred?

And on the other build systems the problem never occurred?

It might have, but according to the description of issue #2439 testmod_fcrypt only fails regularly on the Jenkins build server.

If someone notices a fail, please post it here.

We also observed the exact same error caused by testmod_crypto on Debian Unstable during the last PR (#3395 ).

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

I will rewrite this section to use execv in order to gain a better understanding of what's happening on the build server.

Should the error occur again, please feel free to re-open this issue.

The error occurred again, I'm still researching.

Please ping me if the error occurs again.

Happened with gpgme again. (I don't know if we should open separate issues for every plugin or just keep this meta-issue?)

 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.

I don't know if we should open separate issues for every plugin or just keep this meta-issue?

I think it's the same (or very similar) gpg-related error. I don't think it is necessary to open another issue.

gpgme (or gpgme in combination with valgrind) seems to cause problems if the output of stdout and stderr is being redirected.

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)

I guess this would explain why the test output is written to the log files multiple times.

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

[truncated output]

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

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


gpgme Results: 45 Tests done — 0 errors.

Is this issue fixed now?

@petermax2 rewrote parts of the crypto tests and moved them to separate CI jobs (debian-buster-cryptoplugins and debian-stretch-cryptoplugins).

I have not seen these tests fail since those improvements. I think it can be safely closed.

Glad to hear, that it's working now. Thank you for the feedback!