search for: pthread_cond_wait

Hello, sorry for my later answer. so, after i started libvirtd (no vm´s running) and attach gdb i get the following threads (gdb) info thread Id Target Id Frame 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 9 Thread 0x7f18fdf4c700 (LWP 20697) "libvirtd"...

...> >> sorry for my later answer. >> >> so, after i started libvirtd (no vm´s running) and attach gdb i get the >> following threads >> >> (gdb) info thread >> Id Target Id Frame >> 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" >> pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" >> pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> 9 Thread 0x...

Hi Michal, thank you for your answer. so if i understand that correctly, no matter if i shutdown or destroy the domain and no matter if it is a transient or an persistent vm, the thread should disappear, right? in my case they still exist, also an hour after i destroy the domain (and don´t start any new one). i use libvirt-1.1.35 on fedora core 20, for information. all the best max    

...01.10.2014 10:31, web2 wrote: > Hello, > > sorry for my later answer. > > so, after i started libvirtd (no vm´s running) and attach gdb i get the following threads > > (gdb) info thread > Id Target Id Frame > 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > 9 Thread 0x7f18fdf4c700 (LWP 20697) "lib...

...answer. >>> >>> so, after i started libvirtd (no vm´s running) and attach gdb i get the >>> following threads >>> >>> (gdb) info thread >>> Id Target Id Frame >>> 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" >>> pthread_cond_wait@@GLIBC_2.3.2 () at >>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >>> 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" >>> pthread_cond_wait@@GLIBC_2.3.2 () at >>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >...

...>> events=POLLIN|POLLERR|POLLHUP}, >> {fd=46, events=POLLIN|POLLERR|POLLHUP}, {fd=50, >> events=POLLIN|POLLERR|POLLHUP}, ...], 43, 5000 >> >> # gdb -p 5786 >> (gdb) thread apply all bt >> >> Thread 17 (Thread 0x7f411a9d7700 (LWP 5788)): >> #0 pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> #1 0x00007f4129c2a2e6 in virCondWait (c=c@entry=0x7f412b18ebb8, >> m=m@entry=0x7f412b18eb90) at util/virthread.c:154 >> #2 0x00007f4129c2ada3 in virThreadPoolWorker >> (opaque=opa...

...ed] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007fcf4c75f67d in poll () at ../sysdeps/unix/syscall-template.S:84 84../sysdeps/unix/syscall-template.S: (no such file or directory)没有那个文件或目录. "" Thread 18 (Thread 0x7fcf3a4e8700 (LWP 14799)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fcf4e17ee36 in virCondWait (c=c@entry=0x7fcf3400cc90, m=m@entry=0x7fcf3400cc50) at util/virthread.c:154 #2 0x00007fcf405498a0 in udevEventHandleThread (opaque=<optimized out>) at node_device/n...

...nd run 't a a bt' and > share the output? > > Michal > This is output of gdb 't a a bt' ~5 seconds after that error message appeared in log with remoteDispatchConnectGetAllDomainStats() mentioned. Thread 18 (Thread 0x7fd395ffb700 (LWP 3803)): #0 0x00007fd3bbc1f746 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fd3bc5b3016 in virCondWait () from /usr/lib64/libvirt.so.0 #2 0x00007fd3bc5b3b63 in ?? () from /usr/lib64/libvirt.so.0 #3 0x00007fd3bc5b2db8 in ?? () from /usr/lib64/libvirt.so.0 #4 0x00007fd3bbc186b3 in start_thread () from /lib64/libpthrea...

...to do with dbus/policykit. If anybody got an idea what it could be and point me in the right direction or help further analyzing this issue I'd be very grateful. kind regards Philippe d'Anjou (gdb) thread apply all bt Thread 16 (Thread 0x7f275e916700 (LWP 1973)): #0 0x00007f276b5a06d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0 #2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0 #3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0 #4 0x00007f276b59cdc5 in start_thread () fro...

...e="bind" path="/var/run/vm1.sock"/> <target type="virtio" name="org.guest_agent.0"/> </channel> </devices> </domain> backtrace from gdb t a a bt Thread 11 (Thread 0x7f57484a2700 (LWP 17528)): #0 0x00007f574edda90c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f574f17b246 in virCondWait () from /usr/lib64/libvirt.so.0 #2 0x00007f574f17d26b in virThreadPoolWorker.18087 () from /usr/lib64/libvirt.so.0 #3 0x00007f574f1adef1 in virThreadHelper.17820 () from /usr/lib64/libvirt.so.0 #4 0x00007f574edd...

...ents=POLLIN|POLLERR|POLLHUP}, {fd=49, events=POLLIN|POLLERR|POLLHUP}, {fd=59, events=POLLIN|POLLERR|POLLHUP}, {fd=46, events=POLLIN|POLLERR|POLLHUP}, {fd=50, events=POLLIN|POLLERR|POLLHUP}, ...], 43, 5000 # gdb -p 5786 (gdb) thread apply all bt Thread 17 (Thread 0x7f411a9d7700 (LWP 5788)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f4129c2a2e6 in virCondWait (c=c@entry=0x7f412b18ebb8, m=m@entry=0x7f412b18eb90) at util/virthread.c:154 #2 0x00007f4129c2ada3 in virThreadPoolWorker (opaque=opaque@entry=0x7f412b183ab0) at util/virthrea...

...ery same way as you did 'bt'. Just instead of typing 'bt' you'll >> type 't a a bt'. >> >> Michal > here is backtrace from all threads: > > (gdb) t a a bt > > Thread 11 (Thread 0x7fdd8db82700 (LWP 20321)): > #0 0x00007fdd944b990c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007fdd9476515a in virCondWait () from /usr/lib64/libvirt.so.0 > #2 0x00007fdd9476582b in virThreadPoolWorker () from > /usr/lib64/libvirt.so.0 > #3 0x00007fdd94764dfe in virThreadHelper () from /usr/lib64/libvirt.so.0 > #4...

...gt; > <target type="virtio" name="org.guest_agent.0"/> > </channel> > </devices> > </domain> > > backtrace from gdb > > t a a bt > > Thread 11 (Thread 0x7f57484a2700 (LWP 17528)): > #0 0x00007f574edda90c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f574f17b246 in virCondWait () from /usr/lib64/libvirt.so.0 > #2 0x00007f574f17d26b in virThreadPoolWorker.18087 () from > /usr/lib64/libvirt.so.0 > #3 0x00007f574f1adef1 in virThreadHelper.17820 () from > /usr/lib64/libv...

Hello libvirt-users list, We're catching the same bug since 3.4.0 version (3.3.0 works OK). So, we have process that is permanently connected to libvirtd via socket and it is collecting stats, listening to events and control the VPSes. When we try to 'shutdown' a number of VPSes we often catch the bug. One of VPSes sticks in 'in shutdown' state, no related 'qemu'

...om gbd when its in this state: [root@host ~]# ps axf | grep libvirtd 17010 pts/2 S+ 0:00 \_ grep libvirtd 15555 ? Sl 0:00 libvirtd --daemon [root@host ~]# gdb -p $(pgrep libvirtd) (gdb) t a a bt Thread 17 (Thread 0x2ae648a10700 (LWP 15559)): #0 0x00002ae63d97b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae63b2c01ba in virCondWait (c=<value optimized out>, m=<value optimized out>) at util/virthread.c:154 #2 0x00002ae63b2c13fb in virThreadPoolWorker (opaque=<value optimized out>) at util/virthreadpool.c:124 #3 0x00002ae63b2c0...

...hread_db.so.1". [Current thread is 1 (Thread 0x7fe0cbe4d880 (LWP 9602))] Thread 11 (Thread 0x7fdffa0eb700 (LWP 9699)): #0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fdff00bca00) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fdff00bc9b0, cond=0x7fdff00bc9d8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x7fdff00bc9d8, mutex=0x7fdff00bc9b0) at pthread_cond_wait.c:655 #3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5 #4 0x0...

libvirtd will lock if for example kill programm which established connection, only sigkill + restart helps., to reproduce: virConnectPtr libvirt_connection = virConnectOpen("qemu:///system"); if(libvirt_connection == NULL) { std::cout<<"failed to connect to qemu:///system\n"; exit(-1); } exit(0);

...t; how can i make it ? >> > The very same way as you did 'bt'. Just instead of typing 'bt' you'll > type 't a a bt'. > > Michal here is backtrace from all threads: (gdb) t a a bt Thread 11 (Thread 0x7fdd8db82700 (LWP 20321)): #0 0x00007fdd944b990c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fdd9476515a in virCondWait () from /usr/lib64/libvirt.so.0 #2 0x00007fdd9476582b in virThreadPoolWorker () from /usr/lib64/libvirt.so.0 #3 0x00007fdd94764dfe in virThreadHelper () from /usr/lib64/libvirt.so.0 #4 0x00007fdd944b5d63 in start...

...ad (arg=0x7fc324013ee0) at xs.c:1137 #4 0x00007fc335097b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00007fc3349daa3d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x0000000000000000 in ?? () Thread 11 (Thread 0x7fc330e7f700 (LWP 29170)): #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbd80, m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 #2 0x00007fc3371af0cb in virThreadPoolWorker (opaque=opaque@entry=0x7fc3380db870) at util/virthreadpool.c:103 #3 0x0...

...=49, >events=POLLIN|POLLERR|POLLHUP}, {fd=59, events=POLLIN|POLLERR|POLLHUP}, >{fd=46, events=POLLIN|POLLERR|POLLHUP}, {fd=50, >events=POLLIN|POLLERR|POLLHUP}, ...], 43, 5000 > ># gdb -p 5786 >(gdb) thread apply all bt > >Thread 17 (Thread 0x7f411a9d7700 (LWP 5788)): >#0 pthread_cond_wait@@GLIBC_2.3.2 () at >../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >#1 0x00007f4129c2a2e6 in virCondWait (c=c@entry=0x7f412b18ebb8, >m=m@entry=0x7f412b18eb90) at util/virthread.c:154 >#2 0x00007f4129c2ada3 in virThreadPoolWorker >(opaque=opaque@entry=0x7f412b183ab0)...