[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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

The version 1.3.0 is going to newly add ARM64 support, and the
purpose of this rc version release is for verification by other
architecture maintainers. Please give me a verfication result as a
reply to this mail.

The remaining changes are all bugfixes.

ChangeLog:

 - 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 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 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 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 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 amacapital net>
        Reviewed-by: "Eric W. Biederman" <ebiederm xmission com>
        Signed-off-by: David S. Miller <davem davemloft net>

   Without this fix, gcore exited abnormally at its initialization
   part and so core file is never generated.
   (d hatayama 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 jp fujitsu com)

MD5 CheckSum:

$ md5sum ./crash-gcore-command-1.3.0-rc.tar.gz
0b841985c084e790966800edfd1b5d43  ./crash-gcore-command-1.3.0-rc.tar.gz

--
Thanks.
HATAYAMA, Daisuke

Attachment: crash-gcore-command-1.3.0-rc.tar.gz
Description: application/gzip


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]