Bug 1316539 - unable to attach to certain processes when run in a container
Summary: unable to attach to certain processes when run in a container
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdb
Version: 6.8
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Jan Kratochvil
QA Contact: Arjun Shankar
Lenka Špačková
Depends On: 1186918 1221351
Blocks: 1186913 1361283 1186922 1249835
TreeView+ depends on / blocked
Reported: 2016-03-10 12:40 UTC by Jan Kratochvil
Modified: 2017-03-21 09:00 UTC (History)
18 users (show)

Fixed In Version: gdb-7.2-92.el6
Doc Type: Release Note
Doc Text:
"gdbserver" now supports seamless debugging of processes from containers Prior to this update, when *GDB* was executing inside a Super-Privileged Container (SPC) and attached to a process that was running in another container on Red Hat Enterprise Linux Atomic Host, *GDB* did not locate the binary images of the main executable or any shared libraries loaded by the process to be debugged. As a consequence, *GDB* could have displayed error messages relating to files not being present, or being present but mismatched. Also, *GDB* may have seemed to attach correctly, but subsequent commands may have failed or displayed corrupted information. In Red Hat Enterprise Linux 6.9, "gdbserver" has been extended for seamless support of debugging processes from containers. The Red Hat Enterprise Linux 6.9 version of "gdbserver" newly supports the *qXfer:exec-file:read* and *vFile:setfs* packets. However, the Red Hat Enterprise Linux 6.9 version of "gdb" cannot use these packets. The Red Hat Developer Toolset 4.1 (or later) version of "gdb" is recommended for use with containers and with Red Hat Enterprise Linux 6.9 "gdbserver". The Red Hat Developer Toolset version of "gdbserver" can be used as well. Red Hat Enterprise Linux 6.9 "gdb" can now suggest using "gdbserver" when run with the "-p" parameter (or the "attach" command) and when, at the same time, it detects that the process being attached is from a container. Red Hat Enterprise Linux 6.9 "gdb" now also suggests the explicit use of the "file" command to specify the location of the process executable in the container being debugged. The "file" command does not need to be entered when the Red Hat Developer Toolset version of "gdb" is being used instead. With this update, Red Hat Enterprise Linux 6.9 "gdbserver" provides seamless debugging of processes from containers together with Red Hat Developer Toolset 4.1 (or later) "gdb". Additionally, Red Hat Enterprise Linux 6.9 "gdb" guides the user through the debugging of processes from containers when Red Hat Developer Toolset "gdb" is not available.
Clone Of: 1186918
Last Closed: 2017-03-21 09:00:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0572 0 normal SHIPPED_LIVE gdb bug fix update 2017-03-21 12:22:40 UTC

Comment 1 Jan Kratochvil 2016-03-10 12:43:14 UTC
Is there business interest in supporting debugging of processes inside RHEL-6 docker guests?  Bug 1221351 suggests so but for a comfortable debugging one needs to also access files inside the docker guests - which is what is Bug is about.

It is not about docker RHEL-6 hosts as those are not supported:

Comment 5 Arjun Shankar 2016-11-22 09:36:48 UTC
So, I tried this with a RHEL build of gdb-gdbserver-7.2-92.el6.x86_64 running on a CentOS6 docker image - and a RHEL-7 host with DTS-4.1 gdb (devtoolset-4-gdb-7.11-67.el7.x86_64) installed.

With the older gdb-gdbserver-7.2-90.el6 running in the docker container, I got the expected error when trying to debug remotely from the host:

"warning: Could not load vsyscall page because no executable was specified"

- among several related warnings, like:

"warning: Remote gdbserver does not support determining executable automatically."

With the fixed gdb-gdbserver-7.2-92.el6, running in the docker container I got:

"Reading /root/a.out from remote target..."

... and additional details in the stack trace.

So, this is indeed fixed => moving this bug to VERIFIED.

Finally: bcause this involves installing a RHEL-6 docker image in RHEL-7, it isn't really worth checking in an automated test for it.

Comment 7 errata-xmlrpc 2017-03-21 09:00:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.