search for: virobjectlock

On Mon, Jul 15, 2013 at 3:18 AM, Michal Privoznik <mprivozn@redhat.com>wrote: > > Interesting. If you are still able to reproduce the crash, can you try to > get the line number within virSecurityManagerGenLabel where the crash > happened? I think it's the STREQ line (440 linenr). Question is whether > model or name is NULL. > > I'll try. I'm not sure why

...core dump might > have what you need: Line #442. However, the line numbers for the source > code in the source tree that my Gentoo system is building from does not > match exactly what you listed. > > Line #442 for me is the one containing the "STREQ" macro: > > virObjectLock(mgr); > > for (i = 0; i < vm->nseclabels; i++) { > for (j = 0; sec_managers[j]; j++) > if (STREQ(vm->seclabels[i]->model, sec_managers[j]->drv->name)) > break; > > > I can rebuild with "-O0" and try again....

...wlevellock.S:135 #1 0x00007f79375c411b in _L_lock_812 () from /lib64/libpthread.so.0 #2 0x00007f79375c3fe8 in __GI___pthread_mutex_lock (mutex=0x7f78d80edd30) at ../nptl/pthread_mutex_lock.c:79 #3 0x00007f793b09cd0c in virMutexLock (m=0x7f78d80edd30) at util/virthread.c:89 #4 0x00007f793b07d831 in virObjectLock (anyobj=0x7f78d80edd20) at util/virobject.c:323 #5 0x00007f793b0b71d7 in virDomainObjListFindByID (doms=0x7f78d80edd20, id=1) at conf/domain_conf.c:1237 #6 0x00007f78fe3f7eb3 in libxlDomainEventHandler (data=0x7f78d81ce940, event=0x7f793c30c2e0) at libxl/libxl_domain.c:534 #7 0x00007f793806f7c0 in...

...sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f932e0efdbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7f92ec011c80) at ../nptl/pthread_mutex_lock.c:80 #2 0x00007f932ea37c45 in virMutexLock (m=m@entry=0x7f92ec011c80) at ../../../src/util/virthread.c:89 #3 0x00007f932ea180ca in virObjectLock (anyobj=anyobj@entry=0x7f92ec011c70) at ../../../src/util/virobject.c:388 #4 0x00007f932ea8fd81 in virDomainObjListCopyActiveIDs (payload=0x7f92ec011c70, name=<optimized out>, opaque=0x7f9321817aa0) at ../../../src/conf/virdomainobjlist.c:679 #5 0x00007f932e9ee6cd in virHashForEach (table=0...

...;gdb bt full". The existing core dump might have what you need: Line #442. However, the line numbers for the source code in the source tree that my Gentoo system is building from does not match exactly what you listed. Line #442 for me is the one containing the "STREQ" macro: virObjectLock(mgr); for (i = 0; i < vm->nseclabels; i++) { for (j = 0; sec_managers[j]; j++) if (STREQ(vm->seclabels[i]->model, sec_managers[j]->drv->name)) break; I can rebuild with "-O0" and try again. If I can still trigger the crash, the...

...sv/linux/x86_64/lowlevellock.S:135 > #1 0x00007f932e0efdbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7f92ec011c80) at ../nptl/pthread_mutex_lock.c:80 > #2 0x00007f932ea37c45 in virMutexLock (m=m@entry=0x7f92ec011c80) at ../../../src/util/virthread.c:89 > #3 0x00007f932ea180ca in virObjectLock (anyobj=anyobj@entry=0x7f92ec011c70) at ../../../src/util/virobject.c:388 > #4 0x00007f932ea8fd81 in virDomainObjListCopyActiveIDs (payload=0x7f92ec011c70, name=<optimized out>, opaque=0x7f9321817aa0) at ../../../src/conf/virdomainobjlist.c:679 > #5 0x00007f932e9ee6cd in virHashForEac...

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 using a hook, but the hook doesn't query libvirt back, so it should be safe from this point of view.