Re: [Qemu-devel] [PATCH 0/3] Add a CentOS test image to run docker tests

[Peter Xu <peterx@redhat.com>]

On Wed, Apr 04, 2018 at 10:51:58AM +0800, Fam Zheng wrote:
> Docker testing on patchew has long suffered from 'make check' hangings. The
> cleanness of VM testing is the cure. Now let's add a CentOS 7 image to run the
> tests.  It's purely ad-hoc, but hopefully still easy to understand and use for
> everyone.
> 
> The first patch makes passing source code from host to the container in VM
> working, and is a nice clean up.
> 
> The second patch makes caches work, to speed up repetitive runs like on
> patchew.
> 
> The last patch adds the new image that does the job. Two out of three docker
> tests running on patchew.org are added to the image. I'll wait for Peter to fix
> the 'docker-test-quick@centos6' hanging (oob test) before adding it too.

This hang does not happen on centos7 (tested myself manually).  I
consider this can be related to different default versions of glib2:

centos6: glib2-2.28.8-9.el6.x86_64
centos7: glib2-2.50.3-3.el7.x86_64

(both fetched from docker.io)

qmp-test hangs at oob-test, while QEMU failed to respond to SIGTERM
when trying to take a lock:

#0  0x00007f18eed02334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f18eecfd5d8 in _L_lock_854 () from /lib64/libpthread.so.0
#2  0x00007f18eecfd4a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007f18eb476c9d in ?? () from /lib64/libglib-2.0.so.0
#4  0x0000000000aa6672 in aio_context_unref (ctx=0x225b600) at /root/qemu/util/async.c:497
#5  0x000000000065851c in iothread_instance_finalize (obj=0x225b380) at /root/qemu/iothread.c:129
#6  0x0000000000962d79 in object_deinit (obj=0x225b380, type=0x2199960) at /root/qemu/qom/object.c:462
#7  0x0000000000962e0d in object_finalize (data=0x225b380) at /root/qemu/qom/object.c:476
#8  0x0000000000964146 in object_unref (obj=0x225b380) at /root/qemu/qom/object.c:924
#9  0x0000000000965880 in object_finalize_child_property (obj=0x2257640, name=0x225aca0 "mon_iothread", opaque=0x225b380) at /root/qemu/qom/object.c:1436
#10 0x0000000000962c33 in object_property_del_child (obj=0x2257640, child=0x225b380, errp=0x0) at /root/qemu/qom/object.c:436
#11 0x0000000000962d26 in object_unparent (obj=0x225b380) at /root/qemu/qom/object.c:455
#12 0x0000000000658f00 in iothread_destroy (iothread=0x225b380) at /root/qemu/iothread.c:365
#13 0x00000000004c67a8 in monitor_cleanup () at /root/qemu/monitor.c:4663
#14 0x0000000000669e27 in main (argc=16, argv=0x7ffe33ce3a08, envp=0x7ffe33ce3a90) at /root/qemu/vl.c:4749

Currently I have no quick idea on why the lock was held by anyone
else (I suppose that's the GMainContext's lock), and I'm not sure
whether it could be a glib bug.

-- 
Peter Xu