This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]