Page MenuHome GnuPG
Create Task
Maniphest T3606

failed to build S-Exp (off=0): Cannot allocate memory
Closed, ResolvedPublic
Actions

Description

I am getting frequent failures to run gpg -d using gpg-connect-agent to manage keys.

I am using Arch Linux with GnuPG 2.2.3-1. The output in journalctl is

failed to build S-Exp (off=0): Cannot allocate memory
failed to read the secret key
command 'PKDECRYPT' failed: Cannot allocate memory <gcrypt>
Ohhhh jeeee: ... this is a bug (sexp.c:1460:do_vsexp_sscan)

I have found related issues, e.g. here and here, though these apply to previous versions, and appear to have been closed as fixed.

It is possible that about 3-4 instances of gpg are trying to decrypt simultaneously.

Please let me know if i can provide more useful information. Thanks.

Details

Version
2.2.3

Related Objects
Search...

Event Timeline

yourealwaysbe created this task.Dec 11 2017, 1:04 PM
• werner added a project: libgcrypt.Dec 11 2017, 2:08 PM
• werner added a subscriber: • werner.

Which libgcrypt version are you using (gpg --version shows it)

yourealwaysbe added a comment.Dec 11 2017, 2:59 PM

Version 1.8.1. The full output is

$ gpg --version
gpg (GnuPG) 2.2.3
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/matt/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
• werner added a comment.Dec 12 2017, 9:11 AM

The fatal bug you reported can happen if the process is running out of secure memory. In general it should return an error but there is one place where we assumed the allocation would always succeed. This has meanwhile changed in the repo and will go into 1.8.2 However, this is not the real problem you have but just a wrong error behaviour.

With several connections using large keys, gpg-agent may indeed run out of memory. See T3530 for the solution we implemented. Will go into Libgcrypt 1.8.2 and GnuPG 2.2.4 to be released next week.

• werner triaged this task as Normal priority.Dec 12 2017, 9:11 AM
yourealwaysbe added a comment.Dec 12 2017, 11:15 AM

Great, many thanks.

• gniibe added a parent task: T4255: gpg-agent: "<gcrypt> Cannot allocate memory" with 10 threads decrypting OpenPGP.Dec 12 2018, 7:23 AM
• werner closed this task as Resolved.Dec 12 2018, 8:30 AM
• werner claimed this task.

T3530 describes the solution. In short: Put "auto-expand-secmem" into gpg-agent.conf.