On 17/11/2021 20.59, John Snow wrote:
>
>
> On Wed, Nov 17, 2021 at 2:45 PM Thomas Huth <thuth@redhat.com
> <mailto:thuth@redhat.com>> wrote:
>
> On 17/11/2021 19.13, John Snow wrote:
> >
> >
> > On Wed, Nov 17, 2021 at 5:07 AM Thomas Huth <thuth@redhat.com
> <mailto:thuth@redhat.com>
> > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote:
> >
> >
> > Hi!
> >
> > I think it has been working fine for me a couple of weeks ago,
> > but when I now run:
> >
> > make check SPEED=slow
> >
> > I'm getting a couple of failing iotests... not sure whether
> > these are known issues already, so I thought I'd summarize them
> > here:
> >
> > *** First one is 045 in raw mode: ***
> >
> > TEST iotest-raw: 045 [fail]
> > QEMU --
> >
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-system-x86_64"
> > -nodefaults -display none -accel qtest
> > QEMU_IMG --
> > "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-img"
> > QEMU_IO --
> > "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-io" --cache
> > writeback --aio threads -f raw
> > QEMU_NBD --
> > "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-nbd"
> > IMGFMT -- raw
> > IMGPROTO -- file
> > PLATFORM -- Linux/x86_64 thuth 4.18.0-305.19.1.el8_4.x86_64
> > TEST_DIR --
> /home/thuth/tmp/qemu-build/tests/qemu-iotests/scratch
> > SOCK_DIR -- /tmp/tmphlexdrlt
> > GDB_OPTIONS --
> > VALGRIND_QEMU --
> > PRINT_QEMU_OUTPUT --
> >
> > --- /home/thuth/devel/qemu/tests/qemu-iotests/045.out
> > +++ 045.out.bad
> > @@ -1,5 +1,77 @@
> > -...........
> > +......EE.EE <http://EE.EE> <http://EE.EE <http://EE.EE>>
> >
> +======================================================================
> > +ERROR: test_add_fd (__main__.TestSCMFd)
> >
> +----------------------------------------------------------------------
> > +Traceback (most recent call last):
> > + File "/home/thuth/devel/qemu/tests/qemu-iotests/045", line 148, in
> > test_add_fd
> > + self._send_fd_by_SCM()
> > + File "/home/thuth/devel/qemu/tests/qemu-iotests/045", line 144, in
> > _send_fd_by_SCM
> > + ret = self.vm.send_fd_scm(file_path=image0)
> > + File "/home/thuth/devel/qemu/python/qemu/machine/machine.py", line
> > 229, in send_fd_scm
> > + self._qmp.send_fd_scm(fd)
> > + File "/home/thuth/devel/qemu/python/qemu/aqmp/legacy.py", line
> 138,
> > in send_fd_scm
> > + self._aqmp.send_fd_scm(fd)
> > + File "/home/thuth/devel/qemu/python/qemu/aqmp/protocol.py",
> line 149,
> > in _wrapper
> > + return func(proto, *args, **kwargs)
> > + File "/home/thuth/devel/qemu/python/qemu/aqmp/qmp_client.py", line
> > 644, in send_fd_scm
> > + sock = sock._sock # pylint: disable=protected-access
> > +AttributeError: 'socket' object has no attribute '_sock'
> >
> >
> > Well, that's not good.
> >
> > Can you tell me some details about what system produced this failure?
> > The python version used to run the test would be good, as well as distro
> > release, kernel version, etc.
> >
> > If you can reproduce it, I might want to give you a test branch of the
> > python code to produce some extra debugging information to help me
> > understand what's gone wrong here. Get in touch on IRC when you have
> some
> > spare time if you'd like to interactively debug it.
>
> As you likely saw in Hanna's mail a little bit later, the problem was the
> old version of pylint. I did still have version 2.2 installed - after
> upgrading, the problem went away.
>
>
> upgrading pylint made *this* problem in *045* go away and not just the
> failure in *297*, are you positive?
Ah, no, of course not, I just mixed them up :-/
I was able to repro, I have a fix on the way but I am doing additional testing.
I still have a fix prepared for some device-crash-test behaviors, but I found ... another bug that's even more annoying, so there is more development and testing to do there.
(New problem is: device-crash-test does not set a timeout for QMP connections, so if the binary dies entirely before it dials out to connect to the QMP library in python at all, we will just hang waiting forever. I don't think this is specific to the Async QMP library, either -- it's a problem in machine.py. The iotests users all set a timeout, FWIW, but this is still less than ideal ...)