This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: How to debug test-in-container failures?
- From: DJ Delorie <dj at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 11 Feb 2019 15:42:34 -0500
- Subject: Re: How to debug test-in-container failures?
Florian Weimer <fweimer@redhat.com> writes:
> How can I debug a failure in a test-in-container test? Is there some
> way to get a proper GDB session for the binary?
In theory, you can install gdb and its dependencies into the testroot
and chroot into it. The fake /bin/sh that's in there should be
sufficient to start a gdb. If the build is essentially "native" you may
be able to copy dependencies from the native root, or attach to a
running process if it's hung.
Of course, you could also manually trigger the test in a not-container,
if the conditions of the test can be replicated outside the container.
> Is it necessary to run a full build each time I make some changes to
> libc.so.6 or the test? There seems to be a problem with the makefile
> dependencies, so that changes to the build are not propagated in the
> container, even after:
Right, because a full install is such an expensive operation, we only do
it once. Remove testroot.pristine/install.stamp if you want to repeat
it.
I have mentioned in the past that getting these dependencies correct and
reliable is tricky.
> make
> make subdirs=nss check
I will add that "make nss/tests" also works, but "make -C nss test" no
longer works, as it bypasses the rule that installs the testroot.