From 9f16f6a4874c56051acd75ce4d8ee10f5d2c07a1 Mon Sep 17 00:00:00 2001 From: HATAYAMA Daisuke Date: Tue, 26 Jul 2022 10:18:42 +0900 Subject: [PATCH] coredump: fix unexpected truncation of generated core files Backport from the upstream crash-gcore. commit dbb542e10bfe1b2e21c7927bda9be1d301cfef65 Author: HATAYAMA Daisuke Date: Fri Jun 17 20:38:19 2022 +0900 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 Signed-off-by: HATAYAMA Daisuke --- ...xpected-truncation-of-generated-core.patch | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 crash-gcore-1.6.3-coredump-fix-unexpected-truncation-of-generated-core.patch diff --git a/crash-gcore-1.6.3-coredump-fix-unexpected-truncation-of-generated-core.patch b/crash-gcore-1.6.3-coredump-fix-unexpected-truncation-of-generated-core.patch new file mode 100644 index 0000000..06c78d0 --- /dev/null +++ b/crash-gcore-1.6.3-coredump-fix-unexpected-truncation-of-generated-core.patch @@ -0,0 +1,52 @@ +From dbb542e10bfe1b2e21c7927bda9be1d301cfef65 Mon Sep 17 00:00:00 2001 +From: HATAYAMA Daisuke +Date: Fri, 17 Jun 2022 20:38:19 +0900 +Subject: [PATCH 7/8] 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 +--- + 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 424b0a4..27086d9 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 +