libelektra: fcrypt / gpgme / crypto: test case fails

@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.

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?

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

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.

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.

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.

Please ping me if the error occurs again.

The error occurred again, I’m still researching.

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

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.

Is it at all possible that something times out here?

Maybe! Depending on the implementation of libassuan.