search for: vircondwait

...ut 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/libpthread.so.0 #5 0x00007fd3bb94c76f in clone () from /lib64/libc.so.6 Thread 17 (Thread...

...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 () from /lib64/libpthread.so.0 #5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6...

...rtio" 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 0x00007f574edd6d63 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f574eb0e04d in clone...

...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/virthreadpool.c:124 >> #3 0x00007f4129c2a078 in virThreadHelper (data=<optimized out>) 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/node_device_udev.c:1606 #3 0x00007fcf4e17ec02 in virThreadHelper (data=<optimized out>) at util/virthread.c:2...

...'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_thread () from /lib64/libpthread.so.0 > #5 0x00007fdd941ed0...

...</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 0x00007f574edd6d63 in start_thread () from /lib64/libpthread.so.0 > #5...

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'

...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 0x00002ae63b2c0036 in virThreadHelper (data=<value optimized out>) at util/virthread.c:206...

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);

...ead 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_thread () from /lib64/libpthread.so.0 #5 0x00007fdd941ed04d in clone () from /lib...

...nu/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 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at util/virthreadpthread.c:161 #4...

В письме от Среда, 19-июн-2013 09:35:27 пользователь Michal Privoznik написал: > On 18.06.2013 22:21, Александр wrote: > > В письме от Вторник, 18-июн-2013 12:10:41 пользователь Michal Privoznik > > > > написал: > >> On 18.06.2013 07:14, Александр wrote: > >>> good day, i am trying to create domain via virDomainDefineXML. and my > >>> program

...t regards Holger ===================================================================================== Thread 18 (Thread 0x7f0d495e0700 (LWP 10742)): #0  0x00007f0d55e690bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1  0x00007f0d5892176a in virCondWait (c=c@entry=0x5557f238db28, m=m@entry=0x5557f238db00) at util/virthread.c:154         ret = <optimized out> #2  0x00007f0d58922543 in virThreadPoolWorker (opaque=opaque@entry=0x5557f23848f0) at util/virthreadpool.c:124         data = 0x0         pool = 0x5557f238dac0         cond = 0x555...

...> > > 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_thread () from /lib64/libpthread.so.0 >...

Hello, In the .xml file I use a media which is no longer available. In the past, I got the information media not available and the creation of the VM was stopped - O.k. behavior. Since 3.10 the libvirtd stopped promptly and all open consoles windows and the virt-manager closed promptly. For diagnose: etcsvms1:/kvm/CS8200/M5 # coredumpctl TIME PID UID GID SIG

...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/virthreadpool.c:124 #3 0x00007f4129c2a078 in virThreadHelper (data=<optimized out>) at util/virthread.c:206 #4 0x00007f4...

I am newbie to this gdb debugging. now i did the bt in the debugging. In my side still it showing the error. Following are the stacktrace which i got. Kindly refer the following logs for full information: **** [New Thread 0x7f8503695700 (LWP 20012)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f84f671281e in

...gt;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/virthreadpool.c:124 >#3 0x00007f4129c2a078 in virThreadHelper (data=<optimized out>) at >util/virthread.c:...

...886 : vm: active, event: 6, cost 31.830 secs The threads backtraces is as follows: [Switching to thread 17 (Thread 0x7f12fddf5700 (LWP 32580))] #2 0x00007f12eb26df21 in qemuMonitorSend (mon=mon@entry=0x7f12d0013af0, msg=msg@entry=0x7f12fddf46e0) at qemu/qemu_monitor.c:1075 1075 if (virCondWait(&mon->notify, &mon->parent.lock) < 0) { (gdb) l 1070 PROBE(QEMU_MONITOR_SEND_MSG, 1071 "mon=%p msg=%s fd=%d", 1072 mon, mon->msg->txBuffer, mon->msg->txFD); 1073 1074 while (mon && mon->msg && !mon-&gt...