search for: lwp

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 0x...

...14 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/l...

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    

...; # gdb -p $(pgrep libvirtd) > (gdb) t a a bt > > if you could run those commands and share the output that might shed > more light. > > Michal Unfortunately, gdb also hangs when attaching to libvirt .... root@vm-host:~# gdb -q -p $(pgrep libvirtd) Attaching to process 9556 [New LWP 9557] [New LWP 9558] [New LWP 9559] [New LWP 9560] [New LWP 9561] [New LWP 9562] [New LWP 9563] [New LWP 9564] [New LWP 9565] [New LWP 9566] [New LWP 9567] [New LWP 9568] [New LWP 9569] [New LWP 9570] [New LWP 9571] [New LWP 9572] ^C^C^C^C^C^C^C^C^C^C^C It must be killed with SIGKILL, and libvirtd...

...rank Hoonhout. Asterisk runs fine for a few minutes and then stops accepting new calls. (I have a standalone server with SIP phones and I'm not doing any external registration). Asterisk CVS-04/07/03-09:28:50 0x420e0037 in poll () from /lib/i686/libc.so.6 (gdb) info threads 16 Thread 14351 (LWP 7258) 0x420e187e in select () from /lib/i686/libc.so.6 15 Thread 16398 (LWP 7371) 0x420292e5 in sigsuspend () from /lib/i686/libc.so.6 14 Thread 12301 (LWP 7256) 0x420e0037 in poll () from /lib/i686/libc.so.6 13 Thread 11276 (LWP 7255) 0x420b4b31 in nanosleep () from /lib/i686/libc....

On 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 >...

..., >>> >>> 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...

...gest that the fix there was only for Windows. I'm thinking that either this is a separate problem or it's an example of the same one under LInux, thereby making it moer important for *nix users to upgrade than the release note suggested. Here's GDB's output: [New Thread 88151 (LWP 11848)] [New Thread 89176 (LWP 11849)] [New Thread 90201 (LWP 12075)] [New Thread 91226 (LWP 12076)] [New Thread 92251 (LWP 12091)] [New Thread 93276 (LWP 12092)] [New Thread 94301 (LWP 16133)] [New Thread 95326 (LWP 16134)] [New Thread 96351 (LWP 16146)] [New Thread 97376 (LWP 16147)] [New Thread...

...ul hints in that regard... I'm using (trying to use...) the -fsanitize=thread feature. Though I'm finding the diagnostics rather cryptic, that isn't my issue here. Suddenly, a few days ago, I started getting this error while running the app i'm testing: [New Thread 0x7fcd41ec1700 (LWP 8142)] [New Thread 0x7fcd41692700 (LWP 8143)] [New Thread 0x7fcd40e63700 (LWP 8144)] [New Thread 0x7fcd3bfff700 (LWP 8145)] [New Thread 0x7fcd3b7fe700 (LWP 8146)] [New Thread 0x7fcd3affd700 (LWP 8147)] [New Thread 0x7fcd3a7fc700 (LWP 8148)] [New Thread 0x7fcd39ffb700 (LWP 8149)] [New Thread 0x7fcd3...

...ops processing calls and CLI commands after some time. "Some time" is two hours one day or four hours on another day. On some days, everything works flawlessly ... Whenever chan_sip stops responding, I fire up gdb and I see something like this: (gdb) info thread 25 Thread -1211487312 (LWP 12519) 0xb7ea2523 in poll () from /lib/tls/libc.so.6 24 Thread -1211749456 (LWP 12520) 0xb7fb58ae in accept () from /lib/tls/libpthread.so.0 23 Thread -1212011600 (LWP 12521) 0xb7fb3295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 22 Thread -1215665232 (LWP 12522) 0x...

Ok so it seg faults when I try to dial out through IAX(voiptalk.org), ofcourse it doesn't if I remove allow=speex :P ---- (gdb) run -c Starting program: /usr/sbin/asterisk -c [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 28283)] [New Thread 32769 (LWP 28285)] [New Thread 16386 (LWP 28286)] [Thread 16386 (LWP 28286) exited] [New Thread 32771 (LWP 28287)] Asterisk CVS-HEAD-09/29/04-10:47:05, Copyright (C) 1999-2004 Digium. Written by Mark Spencer <markster@digium.com> ===========================================...

...email: https://www.redhat.com/archives/libvirt-users/2017-February/msg00074.html Here is output of command below: strace -o libvirt.log -f -s 1000 /usr/sbin/libvirtd https://github.com/yuzibo/linux-programming/blob/master/tmp/libvirt.log Here: sudo gdb -p $(pgrep libvirtd) (gdb) t a a bt [New LWP 14781] [New LWP 14782] [New LWP 14783] [New LWP 14784] [New LWP 14785] [New LWP 14786] [New LWP 14787] [New LWP 14788] [New LWP 14789] [New LWP 14790] [New LWP 14791] [New LWP 14792] [New LWP 14793] [New LWP 14794] [New LWP 14795] [New LWP 14796] [New LWP 14799] [Thread debugging using libthread_db...

...; 0x00007ffff6a6ff10 0x00007ffff6a70804 Yes /lib/x86_64-linux-gnu/libutil.so.1 > 0x00007ffff676e610 0x00007ffff67dd056 Yes /lib/x86_64-linux-gnu/libm.so.6 > (*): Shared library is missing debugging information. > (gdb) c > Continuing. > [New Thread 0x7ffff62eb700 (LWP 24498)] > [Thread 0x7ffff62eb700 (LWP 24498) exited] > [New Thread 0x7ffff62eb700 (LWP 24516)] > [Thread 0x7ffff62eb700 (LWP 24516) exited] > [New Thread 0x7ffff62eb700 (LWP 24519)] > [Thread 0x7ffff62eb700 (LWP 24519) exited] > [New Thread 0x7ffff62eb700 (LWP 24536)] > [Thread...

...or details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run Starting program: /usr/lib/firefox/firefox-bin [Thread debugging using libthread_db enabled] [New process 13600] [New Thread -1222121792 (LWP 13600)] [New Thread -1225557104 (LWP 13603)] [New Thread -1235653744 (LWP 13604)] [New Thread -1256916080 (LWP 13605)] [New Thread -1269044336 (LWP 13606)] [New Thread -1277437040 (LWP 13607)] [New Thread -1288701040 (LWP 13608)] [New Thread -1298027632 (LWP 13609)] [New Thread -1306420336 (LWP 136...

...; > > if you could run those commands and share the output that might shed > > more light. > > > > Michal > > Unfortunately, gdb also hangs when attaching to libvirt .... > > root@vm-host:~# gdb -q -p $(pgrep libvirtd) > Attaching to process 9556 > [New LWP 9557] > [New LWP 9558] > [New LWP 9559] > [New LWP 9560] > [New LWP 9561] > [New LWP 9562] > [New LWP 9563] > [New LWP 9564] > [New LWP 9565] > [New LWP 9566] > [New LWP 9567] > [New LWP 9568] > [New LWP 9569] > [New LWP 9570] > [New LWP 9571] > [New LWP...

...>> >> if you could run those commands and share the output that might shed >> more light. >> >> Michal > > Unfortunately, gdb also hangs when attaching to libvirt .... > > root@vm-host:~# gdb -q -p $(pgrep libvirtd) > Attaching to process 9556 > [New LWP 9557] > [New LWP 9558] > [New LWP 9559] > [New LWP 9560] > [New LWP 9561] > [New LWP 9562] > [New LWP 9563] > [New LWP 9564] > [New LWP 9565] > [New LWP 9566] > [New LWP 9567] > [New LWP 9568] > [New LWP 9569] > [New LWP 9570] > [New LWP 9571] > [New LWP...

...x86_64-linux-gnu/libz.so.1 0x00007ffff6a6ff10 0x00007ffff6a70804 Yes /lib/x86_64-linux-gnu/libutil.so.1 0x00007ffff676e610 0x00007ffff67dd056 Yes /lib/x86_64-linux-gnu/libm.so.6 (*): Shared library is missing debugging information. (gdb) c Continuing. [New Thread 0x7ffff62eb700 (LWP 24498)] [Thread 0x7ffff62eb700 (LWP 24498) exited] [New Thread 0x7ffff62eb700 (LWP 24516)] [Thread 0x7ffff62eb700 (LWP 24516) exited] [New Thread 0x7ffff62eb700 (LWP 24519)] [Thread 0x7ffff62eb700 (LWP 24519) exited] [New Thread 0x7ffff62eb700 (LWP 24536)] [Thread 0x7ffff62eb700 (LWP 24536) exited]...

...ht shed > > > > more light. > > > > > > > > Michal > > > Unfortunately, gdb also hangs when attaching to libvirt .... > > > > > > root@vm-host:~# gdb -q -p $(pgrep libvirtd) > > > Attaching to process 9556 > > > [New LWP 9557] > > > [New LWP 9558] > > > [New LWP 9559] > > > [New LWP 9560] > > > [New LWP 9561] > > > [New LWP 9562] > > > [New LWP 9563] > > > [New LWP 9564] > > > [New LWP 9565] > > > [New LWP 9566] > > > [New LWP...

...an you please attach gdb to libvirtd and 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 0x00007...