On Wed, Nov 15, 2023 at 07:23:01AM +0100, Thomas Huth wrote:
> On 15/11/2023 02.15, Nicholas Piggin wrote:
> > On Wed Nov 15, 2023 at 4:29 AM AEST, Thomas Huth wrote:
> > > On 14/11/2023 17.37, Philippe Mathieu-Daudé wrote:
> > > > On 14/11/23 17:31, Thomas Huth wrote:
> > > > > The tests seem currently to be broken. Disable them by default
> > > > > until someone fixes them.
> > > > >
> > > > > Signed-off-by: Thomas Huth <th...@redhat.com>
> > > > > ---
> > > > > tests/avocado/reverse_debugging.py | 7 ++++---
> > > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > >
> > > > Similarly, I suspect https://gitlab.com/qemu-project/qemu/-/issues/1961
> > > > which has a fix ready:
> > > > https://lore.kernel.org/qemu-devel/20231110170831.185001-1-richard.hender...@linaro.org/
> > > >
> > > > Maybe wait the fix gets in first?
> > >
> > > No, I applied Richard's patch, but the problem persists. Does this test
> > > still work for you?
> >
> > I bisected it to 1d4796cd008373 ("python/machine: use socketpair() for
> > console connections"),
>
> Maybe John (who wrote that commit) can help?
I find it hard to believe this commit is a direct root cause of the
problem since all it does is change the QEMU startup sequence so that
instead of QEMU listening for a monitor connection, it is given a
pre-opened monitor connection.
At the very most that should affect the startup timing a little.
I notice all the reverse debugging tests have a skip on gitlab
with a comment:
# unidentified gitlab timeout problem
this makes be suspicious that John's patch has merely made this
(henceforth undiagnosed) timeout more likely to ocurr.
> > which causes this halfway through the test:
> >
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| Traceback (most
> > recent call last):
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| File
> > "/home/npiggin/src/qemu/build/pyvenv/lib/python3.11/site-packages/avocado/core/decorators.py",
> > line 90, in wrapper
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| return
> > function(obj, *args, **kwargs)
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR|
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| File
> > "/home/npiggin/src/qemu/build/tests/avocado/reverse_debugging.py", line
> > 264, in test_ppc64_powernv
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR|
> > self.reverse_debugging()
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| File
> > "/home/npiggin/src/qemu/build/tests/avocado/reverse_debugging.py", line
> > 173, in reverse_debugging
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| g.cmd(b'c')
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| File
> > "/home/npiggin/src/qemu/build/pyvenv/lib/python3.11/site-packages/avocado/utils/gdb.py",
> > line 783, in cmd
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| response_payload
> > = self.decode(result)
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR|
> > ^^^^^^^^^^^^^^^^^^^
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| File
> > "/home/npiggin/src/qemu/build/pyvenv/lib/python3.11/site-packages/avocado/utils/gdb.py",
> > line 738, in decode
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR| raise
> > InvalidPacketError
> > 2023-11-15 10:37:04,600 stacktrace L0045 ERROR|
> > avocado.utils.gdb.InvalidPacketError
> > 2023-11-15 10:37:04,600 stacktrace L0046 ERROR|
> >
> > It doesn't always fail the same gdb command
> > (I saw a bc on line 182 as well). It seems to be receiving a
> > zero length response?
> >
> > No idea what's happening or why ppc seems to be more fragile.
> > Or why changing console connection affects gdb connection?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
