Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
6 replies Latest Post - ‏2013-01-22T17:40:21Z by SystemAdmin
SystemAdmin
SystemAdmin
6902 Posts
ACCEPTED ANSWER

Pinned topic gpg: out of memory while allocating 8192 bytes

‏2013-01-20T05:21:14Z |
We are receiving the below error message when trying to encrypt or decrypt a file on AIX server :

gpg: out of memory while allocating 8192 bytes

gpg process was working for years on the server until the day we started to see this.

This same gpg encryption is working on an other AIX server in the same environment. Many options were tried including copying the gpg from the server that's working on, recycling the server etc. But the error is persisting.

This is not a problem with any one specific id or a group of id's. Any id trying to encrypt/decrypt is getting this error. Hence this is observed at a server level and not at a user or id level.

We have an other server with identical settings where it is working normally. Even restoring the file system from this server didn't help.

The server memory is just fine and is well within limits. Even trying to encrypt / decrypt an empty or a 3 record file is facing a problem, hence its irrespective of the file size or who is trying to encrypt/decrypt it.

Sample Error :

/home>touch simple1
/home >chmod 777 simple1
/home >/opt/TWWfsw/gnupg12/bin/gpg --encrypt-file simple1
You did not specify a user ID. (you may use "-r")

Enter the user ID. End with an empty line: sradithya
gpg: out of memory while allocating 8192 bytes
/home >

The issue that surprises is that it also worked for a day after the crash recovery. Its only the next day that it stopped working.

No visible changes happened in that one day nor any new file systems were restored. The fact that it worked for a day after crash and then lost is perplexing.

Any help or suggestions on this or any clues to look out for would be of a invaluable help to me. Please post any suggestions that you may have.
Updated on 2013-01-22T17:40:21Z at 2013-01-22T17:40:21Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    6902 Posts
    ACCEPTED ANSWER

    Re: gpg: out of memory while allocating 8192 bytes

    ‏2013-01-20T09:44:19Z  in response to SystemAdmin
    my approach would be to compare a truss of the gpg command failing to a truss of the gpg command succeeding. even include library function calls if no clear difference can be observed in function calls.

    you briefly mention a "crash recovery". forum readers might be more eager to respond if you provide more details about what was done and why.

    Regards
    D.
    • SystemAdmin
      SystemAdmin
      6902 Posts
      ACCEPTED ANSWER

      Re: gpg: out of memory while allocating 8192 bytes

      ‏2013-01-20T09:45:42Z  in response to SystemAdmin
      should read: "even include library function calls if no clear difference can be observed in system calls."
    • SystemAdmin
      SystemAdmin
      6902 Posts
      ACCEPTED ANSWER

      Re: gpg: out of memory while allocating 8192 bytes

      ‏2013-01-20T16:57:47Z  in response to SystemAdmin
      HI,

      Thanks for your inputs.

      The Crash Recovery mentioned above was caused due to a hard drive failure which had to be replaced and the server has to be rebooted.

      Could you please let me know how to run a truss command on gpg, so that i can execute and share the output.
    • SystemAdmin
      SystemAdmin
      6902 Posts
      ACCEPTED ANSWER

      Re: gpg: out of memory while allocating 8192 bytes

      ‏2013-01-22T06:17:28Z  in response to SystemAdmin
      The gpg process is not running as a daemon on the server. Its a stand alone software which is invoked by the batch scripts (shell scripts) at scheduled times run by admin ids.

      There is no centralized trustdb for all the id's. There are individual trustdbs for all the admin ids in their own home directories. The trustdbs are not expected to be corrupted and are in tact.

      Please find the encryption outputs run with debug options on the server where it is working and where it isnt.
      Debug output - Server where gpg is working:

      $ /opt/TWWfsw/gnupg12/bin/gpg --debug-all --encrypt-file simple1
      gpg: NOTE: no default option file `/home/a510373/.gnupg/options'
      You did not specify a user ID. (you may use "-r")

      Enter the user ID. End with an empty line: sradithya
      Added 1024g/212DCF43 2013-01-18 "sradithya (Hi) <Aditya.Sr@target.com>"

      Enter the user ID. End with an empty line:
      File `simple1.gpg' exists. Overwrite (y/N)? y
      $ ls -lrt
      -rwxrwxrwx 1 a510373 adwsup 6 Jan 20 13:41 simple1
      -rw-r--r-- 1 a510373 adwsup 347 Jan 20 19:45 simple1.gpg
      Debug output - Server where gpg is NOT working:
      /home/a510373 >/opt/TWWfsw/gnupg12/bin/gpg --debug-all --encrypt-file simple1
      gpg: NOTE: no default option file `/home/a510373/.gnupg/options'
      You did not specify a user ID. (you may use "-r")

      Enter the user ID. End with an empty line: sradithya
      gpg: DBG: fd_cache_open (/home/a510373/.gnupg/pubring.gpg) not cached
      gpg: DBG: iobuf-1.0: open `/home/a510373/.gnupg/pubring.gpg' fd=4
      gpg: DBG: iobuf-1.0: underflow: req=8192
      gpg: DBG: iobuf-1.0: underflow: got=1819 rc=0
      gpg: DBG: parse_packet(iob=1): type=6 length=418 (search.keyring.c.963)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: free_packet() type=6
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: parse_packet(iob=1): type=13 length=37 (search.keyring.c.963)
      gpg: DBG: fd_cache_open (/home/a510373/.gnupg/pubring.gpg) not cached
      gpg: DBG: iobuf-2.0: open `/home/a510373/.gnupg/pubring.gpg' fd=5
      gpg: DBG: iobuf-2.0: underflow: req=8192
      gpg: DBG: iobuf-2.0: underflow: got=1819 rc=0
      gpg: DBG: parse_packet(iob=2): type=6 length=418 (search.keyring.c.963)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: free_packet() type=6
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: fd_cache_open (/home/a510373/.gnupg/pubring.gpg) not cached
      gpg: DBG: iobuf-3.0: open `/home/a510373/.gnupg/pubring.gpg' fd=6
      gpg: DBG: iobuf-3.0: underflow: req=8192
      gpg: DBG: iobuf-3.0: underflow: got=1819 rc=0
      gpg: DBG: parse_packet(iob=3): type=6 length=418 (parse.keyring.c.382)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: parse_packet(iob=3): type=13 length=37 (parse.keyring.c.382)
      gpg: DBG: parse_packet(iob=3): type=2 length=94 (parse.keyring.c.382)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: parse_packet(iob=3): type=12 length=2 (parse.keyring.c.382)
      gpg: DBG: parse_packet(iob=3): type=14 length=269 (parse.keyring.c.382)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(32)
      gpg: DBG: mpi_alloc_limb_space(32)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: parse_packet(iob=3): type=2 length=73 (parse.keyring.c.382)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: parse_packet(iob=3): type=12 length=2 (parse.keyring.c.382)
      gpg: DBG: parse_packet(iob=3): type=6 length=418 (parse.keyring.c.382)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(160)
      gpg: DBG: mpi_alloc_limb_space(160)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: mpi_alloc(1024)
      gpg: DBG: mpi_alloc_limb_space(1024)
      gpg: DBG: free_packet() type=6
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: mpi_free
      gpg: DBG: dummy m_size called
      gpg: DBG: mpi_free_limb_space of size 0
      gpg: DBG: iobuf-3.0: close `file_filter(fd)'
      gpg: DBG: /home/a510373/.gnupg/pubring.gpg: close fd 6
      gpg: DBG: fd_cache_close (/home/a510373/.gnupg/pubring.gpg) new slot created
      gpg: DBG: build_packet() type=6
      gpg: out of memory while allocating 8192 bytes
      Please find the truss outputs run on gpg on the server where it is working and where it isnt.

      Truss output - Server where gpg is working:

      $ t-self --yes --encrypt-files sample3 > truss.out <
      execve("/usr/bin/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("/etc/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("/usr/sbin/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("/usr/ucb/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("/home/adwodadm/bin/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("/usr/bin/X11/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("/sbin/gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      execve("./gpg", 0x2FF22C54, 0x2000FB38) argc: 7
      _exit(127)
      Truss output - Server where gpg is NOT working:

      home> truss /opt/TWWfsw/bin/gpg --verbose --default-recipient-self --yes --encrypt-files sample2 > truss.out
      execve("/usr/bin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/etc/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/usr/sbin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/usr/ucb/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/home/adwodadm/bin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/usr/bin/X11/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/sbin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("./gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("/datastage/adwprod_753_app/Ascential/DataStage/DSEngine/bin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      execve("./gpg", 0x2FF2253C, 0x2000FB38) argc: 7
      truss: 0915-007 Lost control of process.
      gpg: using secondary key D8C00BBB instead of primary key 97DBC284
      gpg: reading from `sample2'
      gpg: writing to `sample2.gpg'
      gpg: ELG-E/AES256 encrypted for: "D8C00BBB test01 (test ods) <michael.lamothe@target.com>"
      gpg: out of memory while allocating 8192 bytes
      • SystemAdmin
        SystemAdmin
        6902 Posts
        ACCEPTED ANSWER

        Re: gpg: out of memory while allocating 8192 bytes

        ‏2013-01-22T15:47:45Z  in response to SystemAdmin
        well i am not on your payroll, so i invest 1 minute:

        compare output of ls -l $(which gpg) for both servers
        • SystemAdmin
          SystemAdmin
          6902 Posts
          ACCEPTED ANSWER

          Re: gpg: out of memory while allocating 8192 bytes

          ‏2013-01-22T17:40:21Z  in response to SystemAdmin
          Thanks for your inputs. I wanted to consolidate some more observations below :

          WRITE/EDIT OPTIONS ARE ONLY FAILING :

          Trying to do an encryption :

          //home> truss /opt/TWWfsw/bin/gpg --verbose --default-recipient-self --yes --encrypt-files sample2 > truss.out
          execve("/usr/bin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/etc/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/usr/sbin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/usr/ucb/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/home/bin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/usr/bin/X11/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/sbin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("./gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("/datastage/aprod_753_app/Ascential/DataStage/DSEngine/bin/gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          execve("./gpg", 0x2FF2253C, 0x2000FB38) argc: 7
          truss: 0915-007 Lost control of process.
          gpg: using secondary key D8C00BBB instead of primary key 97RGV098

          gpg: reading from `sample2'
          gpg: writing to `sample2.gpg'
          gpg: ELG-E/AES256 encrypted for: "D8CDFRRG test01 (test ods) <adserr@abc.com>"
          gpg: out of memory while allocating 8192 bytes

          Please note that it is failing while trying to read the data and write it in the encrypted format.

          Or when we tried editing the keys :

          $ /opt/TWWfsw/bin/gpg --edit-key Joseph Johnson
          gpg (GnuPG) 1.2.3; Copyright (C) 2003 Free Software Foundation, Inc.
          This program comes with ABSOLUTELY NO WARRANTY.
          This is free software, and you are welcome to redistribute it
          under certain conditions. See the file COPYING for details.

          Secret key is available.

          gpg: checking the trustdb
          gpg: out of memory while allocating 8192 bytes
          $

          READ OPERATIONS ARE SUCCEEDING :

          /home/a510373 >/opt/TWWfsw/bin/gpg --list-key
          /home/a510373/.gnupg/pubring.gpg

          pub 1024D/9FA4A9F0 2013-01-18 sradithya (Hi) <Aditya.Sr@abc.com>
          sub 1024g/8CF038A9 2013-01-18

          pub 1024D/45834B11 2013-01-18 sraditya (Hi) <sraditya@gmail.com>
          sub 1024g/3A935DA1 2013-01-18

          /home/a510373 >

          /home/a510373 >/opt/TWWfsw/bin/gpg --version
          gpg (GnuPG) 1.2.3
          Copyright (C) 2003 Free Software Foundation, Inc.
          This program comes with ABSOLUTELY NO WARRANTY.
          This is free software, and you are welcome to redistribute it
          under certain conditions. See the file COPYING for details.

          Home: ~/.gnupg
          Supported algorithms:
          Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
          Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
          Hash: MD5, SHA1, RIPEMD160, TIGER192, SHA256
          Compression: Uncompressed, ZIP, ZLIB
          /home/a510373 >
          Hence, the gpg is trying to use some memory for the write/edits that is currently failing. If we would be able to figure out this memory where it is temporarily trying to store data, we would be able to crack the issue.