Suppress repeated warnings when loading a core file
Backport upstream changes which prevent repeated warnings from being printed when loading a core file (RHBZ 2160211, Lancelot SIX).
This commit is contained in:
Kevin Buettner
parent
57b0ecded6
commit
d5dc87ea90
@ -206,3 +206,8 @@ Patch046: gdb-binutils29988-read_indexed_address.patch
|
||||
# first seen when building with GCC 13.1.1 20230426 (Red Hat ;; 13.1.1-1).
|
||||
Patch047: gdb-rhbz2192105-ftbs-dangling-pointer
|
||||
|
||||
# Backport two commits, 0ad504dd464 and ea70f941f9b, from Lancelot SIX
|
||||
# which prevent repeated warnings from being printed while loading a
|
||||
# core file. (RH BZ 2160211)
|
||||
Patch048: gdb-rhbz2160211-excessive-core-file-warnings.patch
|
||||
|
||||
|
||||
@ -45,3 +45,4 @@
|
||||
%patch -p1 -P045
|
||||
%patch -p1 -P046
|
||||
%patch -p1 -P047
|
||||
%patch -p1 -P048
|
||||
|
||||
@ -45,3 +45,4 @@ gdb-add-index.patch
|
||||
gdb-rhbz1553104-s390x-arch12-test.patch
|
||||
gdb-binutils29988-read_indexed_address.patch
|
||||
gdb-rhbz2192105-ftbs-dangling-pointer
|
||||
gdb-rhbz2160211-excessive-core-file-warnings.patch
|
||||
|
||||
108
gdb-rhbz2160211-excessive-core-file-warnings.patch
Normal file
108
gdb-rhbz2160211-excessive-core-file-warnings.patch
Normal file
@ -0,0 +1,108 @@
|
||||
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
|
||||
From: Kevin Buettner <kevinb@redhat.com>
|
||||
Date: Thu, 29 Jun 2023 18:20:30 -0700
|
||||
Subject: gdb-rhbz2160211-excessive-core-file-warnings.patch
|
||||
|
||||
;; Backport two commits, 0ad504dd464 and ea70f941f9b, from Lancelot SIX
|
||||
;; which prevent repeated warnings from being printed while loading a
|
||||
;; core file. (RH BZ 2160211)
|
||||
|
||||
gdb/corelow.c: avoid repeated warnings in build_file_mappings
|
||||
|
||||
When GDB opens a coredump it tries to locate and then open all files
|
||||
which were mapped in the process.
|
||||
|
||||
If a file is found but cannot be opened with BFD (bfd_open /
|
||||
bfd_check_format fails), then a warning is printed to the user. If the
|
||||
same file was mapped multiple times in the process's address space, the
|
||||
warning is printed once for each time the file was mapped. I find this
|
||||
un-necessarily noisy.
|
||||
|
||||
This patch makes it so the warning message is printed only once per
|
||||
file.
|
||||
|
||||
There was a comment in the code assuming that if the file was found on
|
||||
the system, opening it (bfd_open + bfd_check_format) should always
|
||||
succeed. A recent change in BFD (014a602b86f "Don't optimise bfd_seek
|
||||
to same position") showed that this assumption is not valid. For
|
||||
example, it is possible to have a core dump of a process which had
|
||||
mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM). In
|
||||
such case the core dump does contain the information that portions of
|
||||
this special file were mapped in the host process, but trying to seek to
|
||||
position 0 will fail, making bfd_check_format fail. This patch removes
|
||||
this comment.
|
||||
|
||||
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
||||
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
||||
|
||||
gdb/corelow.c: do not try to reopen a file if open failed once
|
||||
|
||||
In the current implementation, core_target::build_file_mappings will try
|
||||
to locate and open files which were mapped in the process for which the
|
||||
core dump was produced. If the file cannot be found or cannot be
|
||||
opened, GDB will re-try to open it once for each time it was mapped in
|
||||
the process's address space.
|
||||
|
||||
This patch makes it so GDB recognizes that it has already failed to open
|
||||
a given file once and does not re-try the process for each mapping.
|
||||
|
||||
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
||||
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
||||
|
||||
diff --git a/gdb/corelow.c b/gdb/corelow.c
|
||||
--- a/gdb/corelow.c
|
||||
+++ b/gdb/corelow.c
|
||||
@@ -237,6 +237,16 @@ core_target::build_file_mappings ()
|
||||
weed out non-file-backed mappings. */
|
||||
gdb_assert (filename != nullptr);
|
||||
|
||||
+ if (unavailable_paths.find (filename) != unavailable_paths.end ())
|
||||
+ {
|
||||
+ /* We have already seen some mapping for FILENAME but failed to
|
||||
+ find/open the file. There is no point in trying the same
|
||||
+ thing again so just record that the range [start, end) is
|
||||
+ unavailable. */
|
||||
+ m_core_unavailable_mappings.emplace_back (start, end - start);
|
||||
+ return;
|
||||
+ }
|
||||
+
|
||||
struct bfd *bfd = bfd_map[filename];
|
||||
if (bfd == nullptr)
|
||||
{
|
||||
@@ -254,11 +264,10 @@ core_target::build_file_mappings ()
|
||||
if (expanded_fname == nullptr)
|
||||
{
|
||||
m_core_unavailable_mappings.emplace_back (start, end - start);
|
||||
- /* Print just one warning per path. */
|
||||
- if (unavailable_paths.insert (filename).second)
|
||||
- warning (_("Can't open file %s during file-backed mapping "
|
||||
- "note processing"),
|
||||
- filename);
|
||||
+ unavailable_paths.insert (filename);
|
||||
+ warning (_("Can't open file %s during file-backed mapping "
|
||||
+ "note processing"),
|
||||
+ filename);
|
||||
return;
|
||||
}
|
||||
|
||||
@@ -268,18 +277,11 @@ core_target::build_file_mappings ()
|
||||
if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
|
||||
{
|
||||
m_core_unavailable_mappings.emplace_back (start, end - start);
|
||||
- /* If we get here, there's a good chance that it's due to
|
||||
- an internal error. We issue a warning instead of an
|
||||
- internal error because of the possibility that the
|
||||
- file was removed in between checking for its
|
||||
- existence during the expansion in exec_file_find()
|
||||
- and the calls to bfd_openr() / bfd_check_format().
|
||||
- Output both the path from the core file note along
|
||||
- with its expansion to make debugging this problem
|
||||
- easier. */
|
||||
+ unavailable_paths.insert (filename);
|
||||
warning (_("Can't open file %s which was expanded to %s "
|
||||
"during file-backed mapping note processing"),
|
||||
filename, expanded_fname.get ());
|
||||
+
|
||||
if (bfd != nullptr)
|
||||
bfd_close (bfd);
|
||||
return;
|
||||
10
gdb.spec
10
gdb.spec
@ -57,7 +57,7 @@ Version: 13.2
|
||||
|
||||
# The release always contains a leading reserved number, start it at 1.
|
||||
# `upstream' is not a part of `name' to stay fully rpm dependencies compatible for the testing.
|
||||
Release: 2%{?dist}
|
||||
Release: 3%{?dist}
|
||||
|
||||
License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPLv2+ with exceptions and GPL+ and LGPLv2+ and LGPLv3+ and BSD and Public Domain and GFDL
|
||||
# Do not provide URL for snapshots as the file lasts there only for 2 days.
|
||||
@ -1252,10 +1252,14 @@ fi
|
||||
%endif
|
||||
|
||||
%changelog
|
||||
* Wed Jun 28 2023 Python Maint <python-maint@redhat.com>
|
||||
* Fri Jun 30 2023 Kevin Buettner <kevinb@redhat.com> - 13.2-3
|
||||
- Backport upstream changes which prevent repeated warnings from being
|
||||
printed when loading a core file (RHBZ 2160211, Lancelot SIX).
|
||||
|
||||
* Wed Jun 28 2023 Python Maint <python-maint@redhat.com> - 13.2-2
|
||||
- Rebuilt for Python 3.12
|
||||
|
||||
* Sun Jun 25 2023 Alexandra Hájková <ahajkova@redhat.com> - 13.2
|
||||
* Sun Jun 25 2023 Alexandra Hájková <ahajkova@redhat.com> - 13.2-1
|
||||
- Rebase to FSF GDB 13.22.
|
||||
- Remove gdb-rhbz2177655-aarch64-pauth-valid-regcache.patch.
|
||||
- Remove gdb-rhbz2183595-rustc-inside_main.patch.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user