Re: How to debug test-in-container failures?

[Florian Weimer <fweimer at redhat dot com>]

* DJ Delorie:

> 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.

How can I run a GDB installed in the container using the container
harness?

I think I may have an issue which only triggers under the harness, hence
the question.

>> 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.

Ouch.

> 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.

Does “make nss/tests” rebuild the container install?

Thanks,
Florian