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
