From 1bd57575dcb693d7fbda49bee44e81c20d1be7bf Mon Sep 17 00:00:00 2001 From: Luis Machado Date: Wed, 14 Oct 2020 19:11:09 -0300 Subject: [PATCH] Fix gdb.base/corefile2.exp regression when running Docker/AUFS The following failures started showing up after commit bb2a67773c - "Use a std::vector in target_section_table": FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[0]@4 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-4]@4 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[-3]@6 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_rw[pagesize-3]@6 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-3]@6 I tracked it down to a problem in core_target::xfer_partial, at this point: if (!m_core_file_mappings.empty ()) xfer_status = xfer_memory_via_mappings (readbuf, writebuf, offset, len, xfered_len); else xfer_status = this->beneath ()->xfer_partial (object, annex, readbuf, writebuf, offset, len, xfered_len); It seems commit bb2a67773c uncovered a latent bug when handling a particular case where things are running within a Docker container using the AUFS storage driver. When building the file mappings for a core file, we call gdbarch_read_core_file_mappings, which in turn passes a couple lambda callbacks. One pre-loop and one in-loop. The catch is that commit bb2a67773c reworked the pre-loop lambda and made it do nothing. Before that commit, we always allocated m_core_file_mappings in that lambda. Now, when calling the in-loop lambda, we don't touch m_core_file_mappings because the bfd is nullptr (given Docker leaks the host system path, and that file doesn't exist within the container itself). So, instead, we add an entry to the m_core_unavailable_mappings vector. When we reach core_target::xfer_partial, we're only checking for an empty m_core_file_mappings. Given it is now empty, we take the path of reading the contents from the file, not the core file. This reads back unexpected results. The following patch fixes this by also checking for m_core_unavailable_mappings, given core_target::xfer_memory_via_mappings already handles the Docker/AUFS situation. gdb/ChangeLog: 2020-10-22 Luis Machado * corelow.c (core_target::xfer_partial): Also check for an empty m_core_unavailable_mappings vector. --- gdb/ChangeLog | 5 +++++ gdb/corelow.c | 14 ++++++++++---- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index bf93e1b8a26..a976442f9a4 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2020-10-22 Luis Machado + + * corelow.c (core_target::xfer_partial): Also check for an empty + m_core_unavailable_mappings vector. + 2020-10-22 Andrew Burgess * expprint.c (dump_subexp_body_standard): Print RANGE_HAS_STRIDE. diff --git a/gdb/corelow.c b/gdb/corelow.c index d557475e06f..a54d81571aa 100644 --- a/gdb/corelow.c +++ b/gdb/corelow.c @@ -813,10 +813,16 @@ core_target::xfer_partial (enum target_object object, const char *annex, core file provided mappings (e.g. from .note.linuxcore.file or the like) as this should provide a more accurate result. If not, check the stratum beneath us, which should - be the file stratum. */ - if (!m_core_file_mappings.empty ()) - xfer_status = xfer_memory_via_mappings (readbuf, writebuf, offset, - len, xfered_len); + be the file stratum. + + We also check unavailable mappings due to Docker/AUFS driver + issues. */ + if (!m_core_file_mappings.empty () + || !m_core_unavailable_mappings.empty ()) + { + xfer_status = xfer_memory_via_mappings (readbuf, writebuf, offset, + len, xfered_len); + } else xfer_status = this->beneath ()->xfer_partial (object, annex, readbuf, writebuf, offset, len, -- 2.30.2