d5dc87ea90
Backport upstream changes which prevent repeated warnings from being printed when loading a core file (RHBZ 2160211, Lancelot SIX).
109 lines
4.3 KiB
Diff
109 lines
4.3 KiB
Diff
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;
|