import crash-gcore-command-1.6.3-3.el8

This commit is contained in:
CentOS Sources 2022-11-24 06:10:54 +00:00 committed by Stepan Oksanichenko
parent 8bf0450088
commit 03b4c7ecb9
6 changed files with 350 additions and 1 deletions

View File

@ -0,0 +1,114 @@
From 03f9360715731f18e4fdae7b30aa34b30dddcd57 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Date: Sat, 26 Mar 2022 21:42:02 +0900
Subject: [PATCH 1/5] x86: Fix failure of collecting vsyscall mapping due to
change of enum type of vsyscall_mode
vsyscall mapping fails to get collected because the commit
bd49e16e3339 (x86/vsyscall: Add a new vsyscall=xonly mode) merged at
kernel v5.2-rc7 added constant XONLY to the anonymous enumeration type
of variable vsyscall_mode, which made the value of constant NONE
change from 1 to 2.
This commit fixes the issue by checking the value of constant NONE
using gdb's print command and typeof operator since there's no utility
function to handle such anonymous enumeration type currently in crash
utility.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
src/libgcore/gcore_x86.c | 56 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 54 insertions(+), 2 deletions(-)
diff --git a/src/libgcore/gcore_x86.c b/src/libgcore/gcore_x86.c
index 08e573c741f6..f334a85d4240 100644
--- a/src/libgcore/gcore_x86.c
+++ b/src/libgcore/gcore_x86.c
@@ -41,6 +41,9 @@ struct gcore_x86_table
static struct gcore_x86_table gcore_x86_table;
struct gcore_x86_table *gxt = &gcore_x86_table;
+static void gdb_run_command(char *cmd, char *buf, size_t size);
+static int get_vsyscall_mode_none(void);
+
#ifdef X86_64
static ulong gcore_x86_64_get_old_rsp(int cpu);
static ulong gcore_x86_64_get_per_cpu__old_rsp(int cpu);
@@ -2367,6 +2370,54 @@ int gcore_is_arch_32bit_emulation(struct task_context *tc)
return FALSE;
}
+static void gdb_run_command(char *cmd, char *buf, size_t size)
+{
+ open_tmpfile();
+ if (!gdb_pass_through(cmd,
+ pc->tmpfile,
+ GNU_RETURN_ON_ERROR)) {
+ close_tmpfile();
+ error(FATAL, "gdb command failed: %s", cmd);
+ }
+ rewind(pc->tmpfile);
+ fgets(buf, size, pc->tmpfile);
+ close_tmpfile();
+}
+
+static int get_vsyscall_mode_none(void)
+{
+ static int none = -1;
+ char cmd[32], buf[BUFSIZE];
+ int i;
+
+ if (none != -1)
+ return none;
+
+ /*
+ * Variable vsyscall_mode is of anonymous enumeration
+ * type. Because there's no utility function in crash utility
+ * to get value of each constant in specified anonymous
+ * enumeration type, we have no choice but rely on gdb's print
+ * command in combination with typeof operator.
+ */
+ for (i = 0; i < 10; ++i) {
+ snprintf(cmd, sizeof(cmd), "p (typeof(vsyscall_mode))%d", i);
+ gdb_run_command(cmd, buf, sizeof(buf));
+ if (strstr(buf, "NONE"))
+ return none = i;
+ }
+
+ /*
+ * When the above logic doesn't work as expected, use 2, which
+ * is the value on the definition where vsyscall_mode was
+ * first introduced at the commit 3ae36655b97a (x86-64: Rework
+ * vsyscall emulation and add vsyscall= parameter).
+ */
+ none = 2;
+
+ return none;
+}
+
/**
* Return an address to gate_vma.
*/
@@ -2377,7 +2428,8 @@ ulong gcore_arch_get_gate_vma(void)
return 0UL;
if (symbol_exists("vsyscall_mode")) {
- enum { ENUMERATE, NONE } vsyscall_mode;
+ int vsyscall_mode;
+ int none = get_vsyscall_mode_none();
readmem(symbol_value("vsyscall_mode"),
KVADDR,
@@ -2386,7 +2438,7 @@ ulong gcore_arch_get_gate_vma(void)
"gcore_arch_get_gate_vma: vsyscall_mode",
gcore_verbose_error_handle());
- if (vsyscall_mode == NONE)
+ if (vsyscall_mode == none)
return 0UL;
}
--
2.37.1

View File

@ -0,0 +1,59 @@
From 1ba701c1d7bd94cc5a02f51652712acdcbf0875c Mon Sep 17 00:00:00 2001
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date: Tue, 21 Jun 2022 09:15:33 +0000
Subject: [PATCH 2/5] coredump: fix segmentation fault caused by type mismatch
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
crash gcore command on ARM sometimes results in segmentation fault:
crash> gcore -v 0
Segmentation fault (core dumped)
This is caused by type mismatch of a variable paddr in function
gcore_readmem_user() to hold a physical address, which is indicated by
the following warning message:
libgcore/gcore_coredump.c: In function gcore_readmem_user:
libgcore/gcore_coredump.c:85:26: warning: passing argument 2 of
uvtop_quiet from incompatible pointer type
[-Wincompatible-pointer-types]
if (!uvtop_quiet(addr, &paddr)) {
^~~~~~
libgcore/gcore_coredump.c:71:49: note: expected physaddr_t * {aka
long long unsigned int *} but argument is of type ulong * {aka long
unsigned int *}
static int uvtop_quiet(ulong vaddr, physaddr_t *paddr);
~~~~~~~~~~~~^~~~~
On ARM, long unsigned int has 4 byte length, while physaddr_t has 8
byte length. The mismatch causes overwriting of stack variables.
Fix this by changing the type of the variable paddr to physaddr_t.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
src/libgcore/gcore_coredump.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/libgcore/gcore_coredump.c b/src/libgcore/gcore_coredump.c
index c14cc116e951..424b0a40a42b 100644
--- a/src/libgcore/gcore_coredump.c
+++ b/src/libgcore/gcore_coredump.c
@@ -78,7 +78,8 @@ readswap(ulonglong pte_val, char *buf, ulong len, ulonglong vaddr)
void gcore_readmem_user(ulong addr, void *buf, long size, char *type)
{
- ulong paddr, cnt;
+ physaddr_t paddr;
+ ulong cnt;
char *bufptr = buf;
while (size > 0) {
--
2.37.1

View File

@ -0,0 +1,66 @@
From 8ff3de974aa9fdf8934797122dc55428ef571ab2 Mon Sep 17 00:00:00 2001
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date: Tue, 21 Jun 2022 09:15:34 +0000
Subject: [PATCH 3/5] elf: fix warning message caused by type mismatch of
offset types
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Use loff_t consistently to fix these warnings on -m32 builds on 64-bit:
libgcore/gcore_coredump.c: In function writenote:
libgcore/gcore_coredump.c:701:58: warning: passing argument 3 of
gcore->elf->ops->write_note_header from incompatible pointer type
[-Wincompatible-pointer-types]
if (!gcore->elf->ops->write_note_header(gcore->elf, fp, foffset))
^~~~~~~
libgcore/gcore_coredump.c:701:58: note: expected off_t * {aka long
int *} but argument is of type loff_t * {aka long long int *}
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
src/libgcore/gcore_defs.h | 2 +-
src/libgcore/gcore_elf_struct.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/libgcore/gcore_defs.h b/src/libgcore/gcore_defs.h
index 3233ea533ca0..409678e1ad68 100644
--- a/src/libgcore/gcore_defs.h
+++ b/src/libgcore/gcore_defs.h
@@ -1232,7 +1232,7 @@ struct gcore_elf_operations
int (*write_section_header)(struct gcore_elf_struct *this, FILE *fp);
int (*write_program_header)(struct gcore_elf_struct *this, FILE *fp);
int (*write_note_header)(struct gcore_elf_struct *this, FILE *fp,
- off_t *offset);
+ loff_t *offset);
uint64_t (*get_e_phoff)(struct gcore_elf_struct *this);
uint64_t (*get_e_shoff)(struct gcore_elf_struct *this);
diff --git a/src/libgcore/gcore_elf_struct.c b/src/libgcore/gcore_elf_struct.c
index 2aca984cf90f..b31388aa7e28 100644
--- a/src/libgcore/gcore_elf_struct.c
+++ b/src/libgcore/gcore_elf_struct.c
@@ -141,7 +141,7 @@ static int elf64_write_program_header(struct gcore_elf_struct *this, FILE *fp)
}
static int elf64_write_note_header(struct gcore_elf_struct *this, FILE *fp,
- off_t *offset)
+ loff_t *offset)
{
Elf64_Nhdr *n = &((struct gcore_elf64_struct *)this)->nhdr;
@@ -314,7 +314,7 @@ static int elf32_write_program_header(struct gcore_elf_struct *this, FILE *fp)
}
static int elf32_write_note_header(struct gcore_elf_struct *this, FILE *fp,
- off_t *offset)
+ loff_t *offset)
{
Elf32_Nhdr *n = &((struct gcore_elf32_struct *)this)->nhdr;
--
2.37.1

View File

@ -0,0 +1,53 @@
From dbb542e10bfe1b2e21c7927bda9be1d301cfef65 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Date: Fri, 17 Jun 2022 20:38:19 +0900
Subject: [PATCH 4/5] coredump: fix unexpected truncation of generated core
files
Core files generated by crash gcore command are sometimes unexpectedly
truncated. Then, we can get aware of this from the following warning
message output by gdb:
BFD: warning: /root/./core.1.systemd is truncated: expected core file size >= 43606016, found: 43597824
From the investigation, it turned out that this truncation is
occurring when there is no write() operation after the area skipped by
lseek(). Holes are generated only when there is write() operation.
To fix this issue, use ftruncate() to allocate holes explicitly.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
src/libgcore/gcore_coredump.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/libgcore/gcore_coredump.c b/src/libgcore/gcore_coredump.c
index 424b0a40a42b..27086d91468b 100644
--- a/src/libgcore/gcore_coredump.c
+++ b/src/libgcore/gcore_coredump.c
@@ -331,6 +331,21 @@ void gcore_coredump(void)
}
progressf("done.\n");
+ /*
+ * Use ftruncate() to generate holes explicitly, or core file
+ * gets truncated if there is no write() operation after the
+ * area skipped by lseek().
+ */
+ if (fflush(gcore->fp))
+ error(FATAL, "%s: fflush: %s\n",
+ gcore->corename,
+ strerror(errno));
+
+ if (ftruncate(fileno(gcore->fp), ftell(gcore->fp)) < 0)
+ error(FATAL, "%s: ftruncate: %s\n",
+ gcore->corename,
+ strerror(errno));
+
gcore->flags |= GCF_SUCCESS;
}
--
2.37.1

View File

@ -0,0 +1,43 @@
From d2795659986dacc51e98a3d1dbc8b673582c20fe Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Date: Tue, 28 Jun 2022 03:54:46 +0900
Subject: [PATCH 5/5] gcore.mk: fix mismatch of _FILE_OFFSET_BITS when building
gcore.so
On arm and mips, while _FILE_OFFSET_BITS=64 is used when building
gcore.so by make extensions, it is not used by gcore.mk.
Fix this inconsistency by using _FILE_OFFSET_BITS=64 in gcore.mk on
arm and mips.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
src/gcore.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gcore.mk b/src/gcore.mk
index 4af292b79c60..1fd4d84c2ded 100644
--- a/src/gcore.mk
+++ b/src/gcore.mk
@@ -32,7 +32,7 @@ endif
ifeq ($(shell arch), arm)
TARGET=ARM
- TARGET_CFLAGS=
+ TARGET_CFLAGS=-D_FILE_OFFSET_BITS=64
ARCH=SUPPORTED
endif
@@ -44,7 +44,7 @@ endif
ifeq ($(shell arch), mips)
TARGET=MIPS
- TARGET_CFLAGS=
+ TARGET_CFLAGS=-D_FILE_OFFSET_BITS=64
ARCH=SUPPORTED
endif
--
2.37.1

View File

@ -5,7 +5,7 @@
Summary: Gcore extension module for the crash utility Summary: Gcore extension module for the crash utility
Name: crash-gcore-command Name: crash-gcore-command
Version: 1.6.3 Version: 1.6.3
Release: 2%{?dist} Release: 3%{?dist}
License: GPLv2 License: GPLv2
Group: Development/Debuggers Group: Development/Debuggers
Source: https://github.com/fujitsu/crash-gcore/archive/v%{version}/%{name}-%{version}.tar.gz Source: https://github.com/fujitsu/crash-gcore/archive/v%{version}/%{name}-%{version}.tar.gz
@ -20,6 +20,11 @@ Requires: crash >= 5.1.5
Patch0: 0001-coredump-use-MEMBER_-OFFSET-SIZE-instead-of-GCORE_-O.patch Patch0: 0001-coredump-use-MEMBER_-OFFSET-SIZE-instead-of-GCORE_-O.patch
Patch1: 0002-gcore-defs-remove-definitions-and-initializations-fo.patch Patch1: 0002-gcore-defs-remove-definitions-and-initializations-fo.patch
Patch2: 0003-gcore-fix-memory-allocation-failure-during-processin.patch Patch2: 0003-gcore-fix-memory-allocation-failure-during-processin.patch
Patch3: 0001-x86-Fix-failure-of-collecting-vsyscall-mapping-due-t.patch
Patch4: 0002-coredump-fix-segmentation-fault-caused-by-type-misma.patch
Patch5: 0003-elf-fix-warning-message-caused-by-type-mismatch-of-o.patch
Patch6: 0004-coredump-fix-unexpected-truncation-of-generated-core.patch
Patch7: 0005-gcore.mk-fix-mismatch-of-_FILE_OFFSET_BITS-when-buil.patch
%description %description
Command for creating a core dump file of a user-space task that was Command for creating a core dump file of a user-space task that was
@ -30,6 +35,11 @@ running in a kernel dumpfile.
%patch0 -p1 %patch0 -p1
%patch1 -p1 %patch1 -p1
%patch2 -p1 %patch2 -p1
%patch3 -p1
%patch4 -p1
%patch5 -p1
%patch6 -p1
%patch7 -p1
%build %build
make CFLAGS="%{optflags} -Wl,-z,now" -C src -f gcore.mk make CFLAGS="%{optflags} -Wl,-z,now" -C src -f gcore.mk
@ -49,6 +59,10 @@ rm -Rf $RPM_BUILD_ROOT
%doc COPYING %doc COPYING
%changelog %changelog
* Fri Nov 18 2022 Lianbo Jiang <lijiang@redhat.com> - 1.6.3-3
- Update to upstream commit d2795659986d
- Resolves: rhbz#2119697
* Tue Apr 12 2022 Tao Liu <ltao@redhat.com> - 1.6.3-2 * Tue Apr 12 2022 Tao Liu <ltao@redhat.com> - 1.6.3-2
- Rebase to upstream crash-gcore-command-1.6.3 - Rebase to upstream crash-gcore-command-1.6.3
- Fix memory allocation failure issue - Fix memory allocation failure issue