I understand your emulator is s390x. Perhaps, on the emulator, memory layout is different?
I now see that C99 is OK for GnuPG, or at least no problem for gpgscm.

I think that there are two archs: s390 and s390x. Latter is 64-bit and supports 32-bit version as well.
Use of machine word size (32-bit for 32-bit machine, 64-bit for 32-bit machine) is good. That will be update of Diff 1255.
But I don't know how it is achieved easily.
(If we can ignore LLP64, we can use unsigned long.)
Please go ahead that way.

Please decide for _flag access on 64-bit machine, if 32-bit access is better or not.
If 64-bit access is better, update version of {Diff1255} is needed, instead.
unsigned long is not good for LLP64 system. Use unsigned long long for 64-bit system.

Update of the diff, so that we can keep _flag field access to 32-bit on 64-bit machine.

Applied as ebe12be034f0.

I confirmed that it's 64-bit big-endian.
I wrote a patch for testing. D421: padding is needed for 64-bit big endian

If s390x is big-endian, we need padding at the start of the cell structure. So that the _flag can be compatible to the vector element.
I'll see on the porterbox myself, too.

IIUC, cells are used for a place for vector elements.
I'm afraid what happens for memory space not used for vector elements.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Applied already.

Included already.

While I can't reproduce this problem myself, I think I found an issue of gpg-agent passphrase caching.
Double free may happen when multiple threads enter agent_put_cache, for example.

Err... npth repo is not yet added under dev.gnupg.org.
I requested as T3064.

This patch was committed.

I found that FreeBSD also requires -lpthread thing. I also commit the change to the repo.
Tested with FreeBSD 11.0.
I think that TrueOS can be considered as FreeBSD variant.

Fixed in the repo for DragonFlyBSD 4.8 too.

In T2998, NetBSD was fixed.
I'll check for DragonFlyBSD.
IIUC, FreeBSD and OpenBSD has no issue.

It works for me on NetBSD 7.1. Please test.

I tested with NetBSD 7.1 and -lrt is not required.
Nevertheless, it would be required for older NetBSD, so I leave -lrt check for NetBSD.
I'm going to push the change of D415 now.

Could you please look at https://dev.gnupg.org/T2998 ?

In 2.1.19, gpg-agent uses getpeerucred for macOS. I changed it (since it seemed not working). In 2.1.20, gpg-agent now uses getsockopt with LOCAL_PEERPID.
It seems for me that the crash occurs by ucred_free. If this is the case, 2.1.20 fixes this issue.

Fix published in 2.1.19.

Fix published in 2.1.20.

I think that NetBSD also defines single thread version of pthread_* functions in
libc.
How about attached patch in configure.ac?
(You need to generate configure)

D415: 990_npth-netbsd-20170328.diff

It seems that -lrt is required on NetBSD.

Since this is for command-ssh.c, we can't change the protocol (the client is SSH
process, which doesn't use libassuan).
Here, the purpose of the code is getting PID of peer, so, we can do something
except FreeBSD.

I think that it is fixed in: f7f806afa5083617f4aba02fc3b285b06a7d73d4

Sorry, I couldn't find any possible bug for PC/SC access in scdaemon. It looks
like scdaemon crashes when it tries to access card by PC/SC, and it seems that
it crashes there (I mean, in PC/SC).
I believe that this scdaemon's crash is something which is difficult to avoid in
an application.

Anyway, I fixed the issue itself by handling errors of gpg-agent for scdaemon:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=4ce4f2f683a17be3ddb93729f3f25014a97934ad

This patch tried to fix the issue:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=f9acc7d18bb90f47dafe7e32ae92f567756d6b12

I was wrong that PIPE can be select(2)-ed on Windows. This patch changes the
code so that it uses kill(2) on UNIX and SetEvent on Windows
to break the loop.

I think that scdaemon in 2.1.18 would also crash in sandbox environment.
In 2.1.19, I modified ssh-agent emulation code to support multiple tokens.
This change assumes scdaemon returns ENODEV return code and behaves badly, if
scdaemon crashes.
In 2.1.18, the code was somewhat robust and scdaemon crash didn't cause failure.
I am currently looking into the reason why scdaemon crashes.

It seems npth_eselect is for network FDs.

How about this change?

diff --git a/scd/scdaemon.c b/scd/scdaemon.c
index f7e9f83b5..462ff1b3e 100644

• a/scd/scdaemon.c

+++ b/scd/scdaemon.c
@@ -1291,7 +1291,7 @@ handle_connections (int listen_fd)

while (npth_sigev_get_pending(&signo))
  handle_signal (signo);

#else

• ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, t, NULL, NULL);

+ ret = npth_select (nfd+1, &read_fdset, NULL, NULL, t);

saved_errno = errno;

#endif

It is selecting FD which is created by gnupg_create_pipe.

Version information, please.

I cannot replicate this on GNU/Linux with PC/SC (by disable-ccid).
Anyway, I am looking into this issue:

npth_pselect failed: Input/output error - waiting 1s

FYI: It is fixed in 2.1.
Backporting the change to 2.0 will be a bit large, and I hesitate to do that.

Simple workaround is having multiple readers...

Most card readers only support a single card.
(This is the reason why it is not yet implemented.)
Could you please let us know the reader which supports multiple cards?

From my network, when I input:

KEYSERVER --clear hkps://oteiza.siccegge.de

It results the error, because the network to the host is unreachable.
It is likely that it is an error of the network or the server.
And --standard-resolver thing is fixed by my commit.

I think that this bug is related to libdns. Unfortunately, it is not
reproducible for me.

Well, somehow related, I pushed my change:

commit d26c51825e2255fe58305cbc1cd74fa43f80d93e

In my environment, compiling with --disable-libdns or --standard-resolver at
runtime for dirmngr, it works fine. Before the fix, I confirmed that it failed
with --standard-resolver.

Which version of GnuPG are you using? Do you have scdaemon?

Applied to 2.0, too. Will be in 2.0.31.

Fixed in 2.1.16.

Fixed in 2.1.11 and 2.0.30.

Fixed in 2.1.16.

Fixed in 2.1.16. Will be in 2.0.31 as the fix is in the git repo already.