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.

I just merged the current git head over on zelenka, which includes b83903f59ec5d49ac579f263da70ebc8dc3645b5, and managed to still get the same segfaults.

Fwiw b83903f59ec5d49ac579f263da70ebc8dc3645b5.

@gniibe good catch! I'll fix that and we'll see if that improves things.

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

resolved with 94645311f8a3e9ae33643512f87fbef41bf0556f

Please just keep discussing *one* issue per task.

It was run automatically. Installing libbz2-dev did not help.
Output stays the same.

Steps to (hopefully) reproduce
Cloned the developtment branch and reverified the commit hash described in
https://www.gnupg.org/download/git.html
[Removing https://git.gnupg.org/gnupg.git would be great, since cloning that did not work]
$ ./autogen.sh
$ ./configure --sysconfdir=/etc --enable-maintainer-mode && make
$ make check &> check.log
make does not exist also, though cpu seems to not work on

You need the development package installed (e.g. libbz2-dev on Debian-like systems). Then, rerun configure and rebuild.

$ gpg2 --with-colons --list-config compressname
cfg:compressname:nicht komprimiert;ZIP;ZLIB

Adressed in 94645311f8a3e9ae33643512f87fbef41bf0556f.

The 4gb-packet test reads an OpenPGP message compressed with BZIP2. If that test fails, it most certainly means that you compiled GnuPG without support for BZIP2. You can check this with:

'82' is the line of the failing assertion.

fwiw, this remains a problem on 2.1.20: https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=s390x&ver=2.1.20-1&stamp=1491409561&raw=0

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.

Thank you. I just tried:

autoreconf -fiv && ./configure && make && make check
...
Making check in src
Making check in tests
make  check-TESTS
PASS: t-mutex
PASS: t-thread
PASS: t-fork
==================
All 3 tests passed
==================

on NetBSD-7.99.67/amd64.

git://git.gnupg.org/npth.git

Thanks for working on this.
I can't seem to find a link to the repository for testing, can you please point me in the right direction?

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 don't have one of these systems handy to test with, but if the fix in dee026d7 does what it says it does, this sounds like it's probably OK to close in my book. if there are more problems, i'm sure we can re-open it.

Sure:

user@group: make check XTESTS=4gb-packet.scm verbose=4 &> 4gb-packet.scm_execution.log
and content of 4gb-packet.scm.log appended for completeness{F66019}

Time to say good bye my dear bug.

we are now at 2.1.20 - time to mark this one as resolved.

dkg: Can we close this now that 2.1.20 is out?

Fix is in 2.1.20

I think we can close this bug now that we switched off the roundup instace (modulo DNS TTL). Welcome to al-kindi, aka dev.gnupg.org. Old bug reports are redirected to here.

To make this more precise I think above might actually be more then one bug.

Can you please run

cd tests/openpgp
make check XTESTS=4gb-packet.scm verbose=4

This is no a bug but a non-proper installation of libgcrypt. In fact the output
of libgcrypt's "make install" shows hints on how to finish the install; also
pointing to ldconfig.

In general it is not easy to install a newer version of a library on a system
which already has an older version of that library.

Fixed in 348da58fe0c3656e6177c98fef6b4c4331326c8e.

Well, if you ask *this* nicely, then I will most certainly get *right* to it.

You know what I find annoying? Me writing tests, and then on the first sight of
trouble, we back them out or disable them.