[pkg-gnupg-maint] Bug#789246: Bug#789246: Bug#789246: FTBFS amd64

[NIIBE Yutaka]

On 07/09/2015 01:29 AM, Kurt Roeckx wrote:
> 16:25:44.564660 gettimeofday({1436372744, 564670}, NULL) = 0
> 16:25:44.564689 getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={1, 964000}, ...}) = 0
> 16:25:44.564740 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {1, 965043294}) = 0
> 16:25:46.513466 times({tms_utime=0, tms_stime=391, tms_cutime=0, tms_cstime=0}) = 1977487851
> 16:25:46.513555 times({tms_utime=0, tms_stime=391, tms_cutime=0, tms_cstime=0}) = 1977487851
> 16:25:46.513589 gettimeofday({1436372746, 513599}, NULL) = 0
> 16:25:46.513618 getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={3, 912000}, ...}) = 0
> 16:25:46.513646 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {3, 913653640}) = 0
> [...]

I think that the loop is here in libgcrypt (which is going to 'retry' forever):

    https://sources.debian.net/src/libgcrypt20/1.6.3-2/random/random-csprng.c/#L1052

The intention of the code is to avoid same random number sequence
between a process and its child.

I think that PID is cached by the getpid function as we don't see any
syscall for that.

I don't know the reason why it loops on the specific machine.  It
seems that getpid returns different number for each call...
--