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.

Then please fix that. TBH I find it annoying that you did not check that your
commit actually solves the problem. I mean just using the "stable" branch would
have been enough to see that.

It's important that GPGME builds / runs against all versions of GnuPG and most
distros treat test failures as build failures. Now 1.9 will again need patches
or the python bindings disabled which is creating unnecessary work downstream
which already had enough work with the recent releases.

Indeed. We did not address the issues at all, we decided to skip all tests and
some fell through the cracks.

Unfortunately 1.9.0 doesn't address fully the issues:

[ 108s] Traceback (most recent call last):
[ 108s] File "./t-protocol-assuan.py", line 27, in <module>
[ 108s] err = c.assuan_transact('nop')
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/core.py", line 790, in assuan_transact
[ 108s] errorcheck(err)
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/errors.py", line 62, in errorcheck
[ 108s] raise GPGMEError(retval, extradata)
[ 108s] gpg.errors.GPGMEError: GPGME: IPC connect call failed

Two tests fail.

gnupg2-2.1.19-1.fc27.x86_64
libgpg-error-1.27-1.fc27.x86_64
libassuan-2.4.3-2.fc26.x86_64

Which version of _GnUPG_ are you using?

D416: 991_0001-qt-pass-fmt-to-gpgrt_asprintf.patch

Yep

Andre, can we close this bug?

1.9.0 has been released.

Yes, print *a was correct. Could you please do

  print *sc->load_stack[sc->file_i]->curr_line

there?

Thanks, sounds like you have plans to address all three of the problems then.

Cheers

Indeed. I raised the limit to 5, do you think that this is ok?

I see. Let's get back to this after the release of 1.9

The keyserver helpers programs which are the cause for some not too useful error
messages have been removed from 2.1. Thus the error messages are different and
might be better - at least the dirmngr, responsible for fetching keys, can
create a detailed log file.

I tagged this as wontfix because we won't do any chnages to 2.0 anymore, its
EOLed for the end of the year.

Please feel free to re-open this bug if you experience such problems asl with
2.1.19 or higher.

Thanks for reporting.

Hi!

re 1. It is pretty new that the release notes are linked to the NEWS files. We
have a script to do this but it still needs a manual build. Have not yet done
that. For 10 days or so we again have an autobuilder for the website which can
take over the manual build step. Needs to be done. I keep this bug open to
track this.

re 2. The labels attached to the branches aused more confusion than they helped.
The plan is to remove 2.0 entirely (its EOF is in 9 months). The website
should only prominently only show the stble version. And yes, "modern" has been
stable as well.

re 3. To avoid confusion 1.4 has mostly been removed from the frontpage. Same
reason as above. However, somewhere we need to state this.

I've now pulled from the current master head
(caf00915532e6e8e509738962964edcd14fb0654), rebuilt on zelenka with -O0 -g, and
triggered the error again, causing a core file to be dumped.

I copied gpgscm-gdb.py into tests/gpgscm/ , added it to add-auto-load-safe-path
in ~/.gdbinit, and then ran "gdb -c tests/gpgscm/core tests/gpgscm/gpgscm" and
tried to print a, as requested. here's what i got:

0 (sid_s390x-dchroot)dkg@zelenka:~/src/gnupg2/gnupg2/build$ echo
add-auto-load-safe-path
/home/dkg/src/gnupg2/gnupg2/build/tests/gpgscm/gpgscm-gdb.py > /home/dkg/.gdbinit
0 (sid_s390x-dchroot)dkg@zelenka:~/src/gnupg2/gnupg2/build$ gdb -c
tests/gpgscm/core ./tests/gpgscm/gpgscm

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later < GPL license >
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
< GDB Bugs >.
Find the GDB manual and other documentation resources online at:
< GDB Documentation >.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tests/gpgscm/gpgscm...done.
[New LWP 7145]
Core was generated by `./gpgscm ../../../tests/gpgscm/t-child.scm'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000002aae4ecf748 in is_vector (p=0x4634508) at
../../../tests/gpgscm/scheme.c:220
220 INTERFACE INLINE int is_vector(pointer p) { return (type(p)==T_VECTOR); }
(gdb) bt
#0 0x000002aae4ecf748 in is_vector (p=0x4634508) at
../../../tests/gpgscm/scheme.c:220
#1 0x000002aae4ed3470 in vector_elem (vec=0x4634508, ielem=7) at
../../../tests/gpgscm/scheme.c:1349
#2 0x000002aae4ed975e in tailstack_flatten (sc=0x2ab046296f0,
tailstack=0x4634508, i=8, n=7, acc=0x2ab04629838) at
../../../tests/gpgscm/scheme.c:3117
#3 0x000002aae4ed99d4 in callstack_flatten (sc=0x2ab046296f0, i=8, n=7,
acc=0x2ab04629838) at ../../../tests/gpgscm/scheme.c:3155
#4 0x000002aae4ed9af0 in history_flatten (sc=0x2ab046296f0) at
../../../tests/gpgscm/scheme.c:3173
#5 0x000002aae4ed8488 in _Error_1 (sc=0x2ab046296f0, s=0x2aae4efe634 "eval:
unbound variable:", a=0x2ab0462bdd8) at ../../../tests/gpgscm/scheme.c:2777
#6 0x000002aae4eda162 in opexe_0 (sc=0x2ab046296f0, op=OP_EVAL) at
../../../tests/gpgscm/scheme.c:3298
#7 0x000002aae4ee3ef0 in Eval_Cycle (sc=0x2ab046296f0, op=OP_T0LVL) at
../../../tests/gpgscm/scheme.c:5358
#8 0x000002aae4ee5384 in scheme_load_named_file (sc=0x2ab046296f0,
fin=0x2ab04684f90, filename=0x2ab04684d80 "../../../tests/gpgscm/init.scm") at
../../../tests/gpgscm/scheme.c:5748
#9 0x000002aae4ec1ec6 in load (sc=0x2ab046296f0, file_name=0x2aae4efc7d4
"init.scm", lookup_in_cwd=0, lookup_in_path=1) at ../../../tests/gpgscm/main.c:180
#10 0x000002aae4ec22cc in main (argc=0, argv=0x3ffffe44e48) at
../../../tests/gpgscm/main.c:266
(gdb) up 5
#5 0x000002aae4ed8488 in _Error_1 (sc=0x2ab046296f0, s=0x2aae4efe634 "eval:
unbound variable:", a=0x2ab0462bdd8) at ../../../tests/gpgscm/scheme.c:2777
2777 history = history_flatten(sc);
(gdb) print a
$1 = (pointer) 0x2ab0462bdd8
(gdb) print *a
$2 = define-macro
(gdb)

maybe i'm doing something wrong? i'll ask and see whether i can give out an
account on the porterbox for you, justus.

What about gpgme_get_dirinfo ("agent-socket")?

I did not know about that, and that helps a bit, but has the downside that it
uses the GNUPGHOME from the process' environment.

I'm thinking about the following use case. I have created an ephemeral home
directory to contain the results or side-effects of some operation, and now I
want to talk to the agent that serves that particularly home directory. I
cannot use gpgme_get_dirinfo because that uses GNUPGHOME, and I don't want to
change the environment variable because that is a process-global thing and I
don't want to interfere with other threads.

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.

What about

gpgme_get_dirinfo ("agent-socket")

? For testing you can use

GNUPGHOME=/foo/bar gpgme/tests/t-engine-info 2>&1 | grep agent-info

I have looked into this. I installed Debian on an s390 emulator (hercules), but
have been unable to reproduce the problem there, maybe due to the emulation (it
is quite slow on my system, and the gpgscm interpreter seems especially slow,
maybe because of the challenge of doing branch prediction on interpreters).

Your stack trace suggests a memory corruption early during the initialization
("init.scm", the standard library, is being loaded), we see an error being
generated due to an unbound variable (i.e. the environment hash table is
corrupted / does not perform as expected). Then we see a segfault while the
history buffer is flattened into a list for the error message (i.e. hints at a
corruption).

Unfortunately, memory corruption bugs are very hard to detect in gpgscm due to
its use of a custom memory allocator. The allocator allocates large segments
using malloc and hands out cells from that pool as necessary. However, memory
is never freed, so tools like valgrind can not be used to detect use-after-free,
or even most out-of-bounds accesses.

I have been working on the low-level allocator last week trying to make it more
debuggable and memory errors more detectable, e.g. by moving parts of the
interpreter into readonly sections.

As Werner said, a stack trace with less optimizations would be helpful. Also,
is the problem always the same if it happens? If so, it would be interesting to
know what kind of variable is unbound (for that, inspect the 'a' parameter of
'_Error_1' [I'm attaching a pretty-printer for gdb, with that, do 'print a']).

Access to the porter box would be helpful as well.

As of 348da58fe0c3656e6177c98fef6b4c4331326c8e all Python tests are skipped with
GnuPG < 2.1.12.

Thanks very much! I have solved the problem.

Please do not post files in closed formats like Microsoft word. We will only
look at reports in a plain text format.

From your description it looks more like a build problem because Libgcrypt is
already part of Ubuntu and installing a different version is possible but you
need to get some things right. In general I would suggest to write to
gcrypt-devel@gnupg.org