search for: virsecuritymanagergenlabel

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 GDB failed to list line numbers in the backtrace. I will recompile libvirt with "-O0 -g3" and try again. I'm ru...

...> dennis.jenkins.75@gmail.com> wrote: > >> >> 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 GDB failed to list line numbers in the backtrace. I >>...

...; and try again. If I can still trigger the crash, the backtrace might have useful values for the optimized variables. I'll post again in a few minutes. (gdb) bt full #0 0x00007fe4750c5d76 in __strcmp_sse42 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fe47578ad31 in virSecurityManagerGenLabel (mgr=0x7fe4640acfa0, vm=0x7fe4640c5e40) at security/security_manager.c:442 ret = -1 i = <optimized out> j = <optimized out> sec_managers = 0x7fe458001880 seclabel = <optimized out> generated = false __FUNCTION__ = "virSe...

...g : virLXCProcessStart:1139 : > Generating domain security label (if required) > > > ====== end of log ===== > > Segmentation fault (core dumped) > > > > (gdb) bt > #0 0x00007fe4750c5d76 in __strcmp_sse42 () from /lib64/libc.so.6 > #1 0x00007fe47578ad31 in virSecurityManagerGenLabel () from > /usr/lib64/libvirt.so.0 > #2 0x00007fe46aa92979 in virLXCProcessStart () from > /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so > #3 0x00007fe46aa9736e in lxcDomainCreateWithFlags () from > /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so > #4 0x0...

...manually adding that to my domain. > > In any event, libvirtd should probably not crash due to the XML element > (which seems valid - or at least "virsh edit" allows it). > 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. src/security/security_manager.c-438- for (i = 0; i < vm->nseclabels; i++) { src/security/security_manager.c-439- for (j = 0; sec_managers[j]; j++) src/security/securi...

...host devices 2013-07-12 16:43:31.741+0000: 21365: debug : virLXCProcessStart:1139 : Generating domain security label (if required) ====== end of log ===== Segmentation fault (core dumped) (gdb) bt #0 0x00007fe4750c5d76 in __strcmp_sse42 () from /lib64/libc.so.6 #1 0x00007fe47578ad31 in virSecurityManagerGenLabel () from /usr/lib64/libvirt.so.0 #2 0x00007fe46aa92979 in virLXCProcessStart () from /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so #3 0x00007fe46aa9736e in lxcDomainCreateWithFlags () from /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so #4 0x00007fe47569c067 in virDomainCr...

Hello all, I have two issues: 1) I am unable to start a seemingly correct LXC domain (I cloned it from a working domain). 2) I am able to crash "libvirtd" by attempting to start the cloned domain, but starting the original works just fine. I humbly submit that item #2 is a bug - the "libvirtd" daemon should never crash due to anything the "libvirt" client