[Crash-utility] [ANNOUNCE] crash gcore command, version 1.3.0 is released

HATAYAMA Daisuke d.hatayama at jp.fujitsu.com
Tue Nov 4 05:51:45 UTC 2014


This is the release of crash gcore command, version 1.3.0.

This release newly adds ARM64 and PPC64 supports, thanks to respective
maintainers for their development of patch sets and verifications at
each rc release.

The remaining changes are all bugfixes.

# The ChangeLog includes those that appeared at each rc release.

ChangeLog:

[new features]

 - Add ARM64 support. In addition to native ARM64 build, like crash
   utility, we can build x86_64 executable of crash gcore command for
   ARM64 crash dump by make target=ARM64, just like crash utility.
   (anderson at redhat.com)

 - Add ARM64 compat mode support. This allows gcore to create
   corefiles for tasks running in 32-bit compatible mode on ARM64.
   (weishu at marvell.com)

 - Add PPC64 support. This includes both big-endian and little-endian
   formats.
   (mtoman at redhat.com, anderson at redhat.com)

[bugfixes]

 - Correct a read buffer size for NT_FPREGSET as sizeof(struct
   user_i387_struct). So far we had used sizeof(union thread_xstate)
   falsely as a read buffer size but it had accidentally been equal to
   sizeof(struct user_i387_struct). However, the following patch
   extended union thread_xstate and sizeof(union thread_xstate) became
   larger than sizeof(struct user_i387_struct):

    commit e7d820a5e549b3eb6c3f9467507566565646a669
    Author: Qiaowei Ren <qiaowei.ren at intel.com>
    Date:   Thu Dec 5 17:15:34 2013 +0800

        x86, xsave: Support eager-only xsave features, add MPX support

        Some features, like Intel MPX, work only if the kernel uses eagerfpu
        model.  So we should force eagerfpu on unless the user has explicitly
        disabled it.

        Add definitions for Intel MPX and add it to the supported list.

        [ hpa: renamed XSTATE_FLEXIBLE to XSTATE_LAZY and added comments ]

        Signed-off-by: Qiaowei Ren <qiaowei.ren at intel.com>
        Link: http://lkml.kernel.org/r/9E0BE1322F2F2246BD820DA9FC397ADE014A6115@SHSMSX102.ccr.corp.intel.com
        Signed-off-by: H. Peter Anvin <hpa at linux.intel.com>

   Without this patch, for vmcores whose kernel versions are v3.14 or
   later, gcore results in segmentation fault due to a buffer overrite
   of NT_FPREGSET.
   (d.hatayama at jp.fujitsu.com)

 - Although ELF_DATA is defined in gcore_defs.h, ELFDATA2LSB is used
   directly at elf{64,32}_fill_elf_header(). There's so far been no
   problem since the exisitng supported architectures are all
   little-endian systems. Fix this to support PPC64 that uses
   little-endian format.
   (anderson at redhat.com)

 - Fix a bug that registers in NT_PRSTATUS note information is
   broken. This had been since v1.2.2 when O(1) note informaiton
   collection was added. Without this fix, we can never get reliable
   register values for failure analysis.
   (weishu at marvell.com)

 - Fix a bug that NT_386_IOPERM note information is not collected. So
   far, ioperm_get() had always returned 1. As a result, NT_386_IOPERM
   note information had never been not included in a generated core
   file even if it is available for a given task on a given crash
   dump.
   (d.hatayama at jp.fujitsu.com)

 - Add new member offset initialization for struct
   nsproxy::pid_ns_for_children. In upstream, the following patch
   renamed struct nsproxy::pid_ns into struct
   nsproxy::pid_ns_for_children.

    $ git log -1 c2b1df2e
    commit c2b1df2eb42978073ec27c99cc199d20ae48b849
    Author: Andy Lutomirski <luto at amacapital.net>
    Date:   Thu Aug 22 11:39:16 2013 -0700

        Rename nsproxy.pid_ns to nsproxy.pid_ns_for_children

        nsproxy.pid_ns is *not* the task's pid namespace. The name
        should clarify that.

        This makes it more obvious that setns on a pid namespace is weird --
        it won't change the pid namespace shown in procfs.

        Signed-off-by: Andy Lutomirski <luto at amacapital.net>
        Reviewed-by: "Eric W. Biederman" <ebiederm at xmission.com>
        Signed-off-by: David S. Miller <davem at davemloft.net>

   Without this fix, gcore exited abnormally at its initialization
   part and so core file is never generated.
   (d.hatayama at jp.fujitsu.com)

 - Fix a bug that a wrong way of checking return value of
   fopen(). fopen() returns NULL in case of error, but gcore had seen
   it as returning a minus integer. As a result, gcore continues
   execution after the check even in case of error and then exits
   abnormally at the first call of fwrite() with the broken file
   pointer gcore failed to open.

   From users' viewpoint, we face this bug when trying to overwrite an
   existing corefile with more priviledged permission and resulting in
   EPERM failure.
   (d.hatayama at jp.fujitsu.com)

MD5 CheckSum:

$ md5sum ./crash-gcore-command-1.3.0.tar.gz
d530b7211793f1541a0da5968a305f4d  ./crash-gcore-command-1.3.0.tar.gz

--
Thanks.
HATAYAMA, Daisuke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash-gcore-command-1.3.0.tar.gz
Type: application/octet-stream
Size: 51083 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20141104/698d6c5c/attachment.obj>


More information about the Crash-utility mailing list