search for: libpthread

...utput? > > 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/libpthread.so.0 #5 0x00007fd3bb94c76f in clone...

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

..."/> <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 0x00007f574edd6d63 in start_thread () from /lib64/libp...

...created. Problem happens volumes created but in stopped state. Problem also happens when volumes started state. Below is the 5 stack traces taken by 10 min intervals and volumes stopped state. --1-- Thread 8 (Thread 0x7f413f3a7700 (LWP 104249)): #0 0x0000003d99c0f00d in nanosleep () from /lib64/libpthread.so.0 #1 0x00007f4146312d57 in gf_timer_proc () from /usr/lib64/libglusterfs.so.0 #2 0x0000003d99c07aa1 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003d998e8bbd in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7f413e9a6700 (LWP 104250)): #0 0x0000003d99c0f585 in sigwait () from /...

...ally not a *hang* . Due to the costly handshaking operations for too many bricks from too many nodes, the glusterd takes a quite long amount of time to finish the handshake. > > --1-- > Thread 8 (Thread 0x7f413f3a7700 (LWP 104249)): > #0 0x0000003d99c0f00d in nanosleep () from /lib64/libpthread.so.0 > #1 0x00007f4146312d57 in gf_timer_proc () from > /usr/lib64/libglusterfs.so.0 > #2 0x0000003d99c07aa1 in start_thread () from /lib64/libpthread.so.0 > #3 0x0000003d998e8bbd in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7f413e9a6700 (LWP 104250)): > #0 0x0000003...

.../glusterd_pstack.zip?dl=0 > >> >>> > >> >>> Content of the first stack trace is here: > >> >>> > >> >>> Thread 8 (Thread 0x7f7a8cd4e700 (LWP 43069)): > >> >>> #0 0x0000003aa5c0f00d in nanosleep () from /lib64/libpthread.so.0 > >> >>> #1 0x000000303f837d57 in ?? () from /usr/lib64/libglusterfs.so.0 > >> >>> #2 0x0000003aa5c07aa1 in start_thread () from > /lib64/libpthread.so.0 > >> >>> #3 0x0000003aa58e8bbd in clone () from /lib64/libc.so.6 > >> &...

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

...=0x0, callerid=0x821e5b0 "562390", action=136482640) at pbx.c:532 #5 0x080c7041 in __ast_pbx_run (c=0x82496a8) at pbx.c:2314 #6 0x080c7fd1 in pbx_thread (data=0x64) at pbx.c:2631 #7 0x080f7e99 in dummy_start (data=0x64) at utils.c:843 #8 0xb7f7f13d in pthread_start_thread () from /lib/libpthread.so.0 #9 0xb7ea81ba in clone () from /lib/libc.so.6 (gdb) bt full #0 0xb7e5a231 in strcasecmp () from /lib/libc.so.6 No symbol table info available. #1 0xb7ce0a3f in local_ast_moh_start (chan=0x82496a8, mclass=0xb720f828 "default", interpclass=0x0) at res_musiconhold.c:646...

...ame="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 star...

...release mainly affects the build & distribution process - the primary change to the installed contents is the removal of some no-longer needed variables from the pthread-stubs.pc file. Alan Coopersmith (3): Build xz tarballs instead of bzip2 gitlab CI: add a basic build test libpthread-stubs 0.5 Eric Engestrom (1): pthread-stubs.pc: remove no longer used variables Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: libpthread-stubs-0.5 https://xorg.freedesktop.org/a...

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

...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 0x00002ae63b2c0036 in virThreadHelper (data=<value...

...007f2a453dffdb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #5 0x00007f2a4521af1a in QThread::exec() () at /usr/lib64/libQt5Core.so.5 #6 0x00007f2a4521f9e9 in () at /usr/lib64/libQt5Core.so.5 #7 0x00007f2a40853734 in start_thread () at /lib64/libpthread.so.0 #8 0x00007f2a4491cd3d in clone () at /lib64/libc.so.6 Thread 47 (Thread 0x7f28b37fe700 (LWP 5273)): #0 0x00007f2a3fc577d4 in g_mutex_unlock () at /usr/lib64/libglib-2.0.so.0 #1 0x00007f2a3fc16436 in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #2 0x00007f2a4543232b in QEvent...

Hi, On 64 bit centos 5.6 I have virtualbox 4 and 64 bit elastix latest. Since yesterday cpu utilization has been constantly peaking 65-75%. Hardly 1-2 concurrent calls. No other activity on server. Top shows asterisk on top. Its quad xeon server with 4 gb ram. Any suggestion where should I start and how should I go about with my investigation. Thank you and have a great weekend. Sans

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

...plain things better. Here is a example with a state diagram on how the above proposal works. The main idea is to keep a running state of the resolver and the capturing the resolver state of each input file in the group by the linkingcontext. lld -flavor gnu main.o thread.o --start-group libc.a libpthread.a --end-group function.o main.o has atoms ------------------------ main (defined) printf(undefined) fn(undefined) thread.o has atoms ----------------------------- pthread_create (undefined) libc.a(printf.o) has atoms ------------------------------------ printf(defined) libc.a(exit.o) has atoms...

...: (gdb) c Continuing. thread apply all bt [New Thread 0x7fc337c6b700 (LWP 29520)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) thread apply all bt Thread 12 (Thread 0x7fc337c6b700 (LWP 29520)): #0 0x00007fc33509f18d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007fc32b1555c4 in read_all (fd=26, data=0x7fc3380e0a70, data@entry=0x20, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:365 #2 0x00007fc32b1556d8 in read_message (h=h@entry=0x7fc324013ee0, nonblocking=nonblocking@entry=0) at xs.c:1071 #3 0x00007fc32b156005 in read_thread...

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'

В письме от Среда, 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

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