Blob Blame History Raw
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 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 <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