[PATCH] Fix gdb.base/corefile2.exp regression when running Docker/AUFS

Luis Machado luis.machado@linaro.org
Thu Oct 22 14:24:34 GMT 2020


On 10/18/20 7:29 PM, Kevin Buettner wrote:
> On Wed, 14 Oct 2020 20:03:13 -0300
> Luis Machado <luis.machado@linaro.org> wrote:
> 
>> 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.
>>
>> Validated on x86_64-linux and aarch64-linux on Ubuntu 18.04.
>>
>> Kevin, does this look sane?
>>
>> gdb/ChangeLog:
>>
>> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>
>>
>> 	* corelow.c (core_target::xfer_partial): Also check for an empty
>> 	m_core_unavailable_mappings vector.
> 
> Hi Luis,
> 
> Thanks for figuring this out!
> 
> Your patch looks good to me.
> 
> Kevin
> 

Thanks. Pushed now.


More information about the Gdb-patches mailing list