similar to: error : virHashForEach:597 : Hash operation not allowed during iteration

❦ 4 avril 2018 11:17 +0200, Michal Privoznik <mprivozn@redhat.com> : > Dunno, this is the first time I hear about this issue. Maybe you can try > to set a break point on virHashIterationError() and when it's hit get > stacktrace of all threads 't a a bt'. That might shed more light into > the issue. Smells like we are not locking somewhere properly. So, we have two

On 04/04/2018 02:59 PM, Vincent Bernat wrote: > ❦ 4 avril 2018 11:17 +0200, Michal Privoznik <mprivozn@redhat.com> : > >> Dunno, this is the first time I hear about this issue. Maybe you can try >> to set a break point on virHashIterationError() and when it's hit get >> stacktrace of all threads 't a a bt'. That might shed more light into >> the

hello, I attached core dump - not sure if it was what you have asked for I am rather just admin not developer :) Regards, Rafal Wojciechowski W dniu 20.04.2017 o 16:44, Pavel Hrdina pisze: > On Thu, Apr 20, 2017 at 07:36:42AM +0200, Rafał Wojciechowski wrote: >> hello, >> >> I am getting such error: >> libvirtd[27218]: segfault at 0 ip 00007f4940725721 sp

On 11/15/2017 06:54 AM, Holger Schranz wrote: > Thread 1 (Thread 0x7f4a069cc700 (LWP 10178)): > #0 0x00007f49ff969170 in qemuDomainChangeEjectableMedia ( > driver=driver@entry=0x7f49f841b700, vm=vm@entry=0x7f49ec02fbd0, > disk=disk@entry=0x7f49ec0375d0, newsrc=0x7f49e8014d10, force=force@entry=false) > at qemu/qemu_hotplug.c:303 This is fixed in current upstream by

On Tue, Nov 14, 2017 at 07:19:01PM +0100, Holger Schranz wrote: > Ups ... my fault ... > > libvirtd instead libvirt .... > > > etcsvms5:/var/lib/systemd/coredump # coredumpctl info libvirtd >            PID: 10177 (libvirtd) >            UID: 0 (root) >            GID: 0 (root) >         Signal: 11 (SEGV) >      Timestamp: Tue 2017-11-14 10:11:32 CET (9h ago)

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

i did the debugging as you said. Kindly refer the following logs: (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

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

❦ 4 avril 2018 15:19 +0200, Michal Privoznik <mprivozn@redhat.com> : > Both threads call virHashForEach(table=0x7f92fc69a480). Thread 6 was > first so it starts iterating and sets table->iterating so later when > thread 10 enters the function an error is reported. > > I guess we can go with what Dan suggested and after some rework we can > just drop ->iterating

On 04/04/2018 10:36 AM, Vincent Bernat wrote: > Hey! > > On many of our servers, we often have the following error: > > error : virHashForEach:597 : Hash operation not allowed during iteration > > When querying the list of domains, this means libvirt will silently > return 0 domain (most uses of virHashForEach don't handle the return > code). > > We are

On 04/04/2018 03:48 PM, Vincent Bernat wrote: > ❦ 4 avril 2018 15:19 +0200, Michal Privoznik <mprivozn@redhat.com> : > >> Both threads call virHashForEach(table=0x7f92fc69a480). Thread 6 was >> first so it starts iterating and sets table->iterating so later when >> thread 10 enters the function an error is reported. >> >> I guess we can go with what

❦ 4 avril 2018 16:21 +0200, Vincent Bernat <bernat@luffy.cx> : >> You can do that locally, but as a patch it's very unlikely to be >> accepted upstream because we've introduced RW locks to be able to access >> domain list from multiple threads. > > Looking a bit more, the whole "iterating" bit is currently > unsafe. First, it is racy since

❦ 4 avril 2018 17:00 +0200, Vincent Bernat <bernat@luffy.cx> : >>> You can do that locally, but as a patch it's very unlikely to be >>> accepted upstream because we've introduced RW locks to be able to access >>> domain list from multiple threads. >> >> Looking a bit more, the whole "iterating" bit is currently >> unsafe.

On 04/04/2018 08:38 PM, Vincent Bernat wrote: > 0001-util-don-t-check-for-parallel-iteration-in-hash-rela.patch > > > From 7bf32825325b124edce58687a8cd2ceff13328b9 Mon Sep 17 00:00:00 2001 > From: Vincent Bernat <vincent@bernat.im> > Date: Wed, 4 Apr 2018 16:25:37 +0200 > Subject: [PATCH] util: don't check for parallel iteration in hash-related > functions Can

❦ 5 avril 2018 17:00 +0200, Michal Privoznik <mprivozn@redhat.com> : >> 0001-util-don-t-check-for-parallel-iteration-in-hash-rela.patch >> >> >> From 7bf32825325b124edce58687a8cd2ceff13328b9 Mon Sep 17 00:00:00 2001 >> From: Vincent Bernat <vincent@bernat.im> >> Date: Wed, 4 Apr 2018 16:25:37 +0200 >> Subject: [PATCH] util: don't check

❦ 4 avril 2018 15:59 +0200, Michal Privoznik <mprivozn@redhat.com> : >> I may have missed this suggestion. Maybe Dan only sent it to you? > > No, there is another thread where this issue is discussed: > > https://www.redhat.com/archives/libvir-list/2018-April/msg00190.html > > In the >> meantime, could I change the locks around virHashForEach() and similar

Hi, I'm having problems with libvirt crashing after a couple hours when a specific domain monitoring program is running. I have pasted below the following: 1. libvirt version 2. qemu-kvm version 3. OS version 4. Kernel version 5. libvirt status post-crash 6. libvirtd.log (info level dump around crash; too long to post everything so just the beginning and end. UTC) 7. custom.log (on what

On Thu, Apr 20, 2017 at 06:10:04PM +0200, Rafał Wojciechowski wrote: > hello, > > I attached core dump - not sure if it was what you have asked for > I am rather just admin not developer :) > > Regards, > > Rafal Wojciechowski The attached core send in private mail helped to figure out where the crash happened. Backtrace: Thread 1 (Thread 0x7f194b99d700 (LWP 5631)):

Hi, all, We were running OpenStack with Ubuntu and libvirt 0.9.10. We found that libvirt monitor command not working well. There were a lot of error in libvirtd.log like this 2013-02-07 06:07:39.000+0000: 18112: error : qemuDomainObjBeginJobInternal:773 : Timed out during operation: cannot acquire state change lock We dig into libvirtd by strace and find one of the thread only have the following

Hi, first sorry for the cross-posting, but i don ́t known exactly if my problem belongs to xen or libvirt. I have an VM-Host with Xen 4.6.0 und libvirt 1.2.19. The Job of the Host is to resume in parallel 20 VM ́s (HVM WinXp) attach a block-device to each VM , wait 60 Seconds, kill the VM and start from beginning. For that, a python script create for each vm a thread and each thread get a