Ah ha! I just learned about "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 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__ = "virSecurityManagerGenLabel" __func__ = "virSecurityManagerGenLabel" #2 0x00007fe46aa92979 in virLXCProcessStart (conn=0x7fe460000a80, driver=0x7fe4640bd340, vm=0x7fe4640c1610, autoDestroy=false, reason=VIR_DOMAIN_RUNNING_BOOTED) at lxc/lxc_process.c:1144 rc = -1 r = <optimized out> nttyFDs = 1 ttyFDs = 0x7fe458001790 i = <optimized out> logfile = 0x7fe458000ad0 "/var/log/libvirt/lxc/dwj-hfax-dev.log" logfd = -1 nveths = 0 veths = 0x0 handshakefds = {-1, -1} pos = -1 ebuf = "\000\000\000\000\344\177\000\000\020\000\000\000\000\000\000\000\376\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\377\377\377\377", '\000' <repeats 12 times>"\364, \377\377\377\377\377\377\377\220Y|u\344\177\000\000\034\313\376t\344\177\000\000\000\000\000\000\020\000\000\000\217\b~u\344\177\000\000\000\000\000\000\000\000\000\000\250\246\327o\344\177\000\000t\b~u\344\177\000\000\000\000\000\000\000\000\000\000\020", '\000' <repeats 15 times>, "P\251\327o", '\000' <repeats 12 times>, "\006\247\327o\344\177\000\000\034\313\376t\344\177\000\000\000\000\000\000\344\177\000\000C\342{u\344\177\000\000x\247\327o\344\177\000\000\b\247\327o2739\000\342{u\344\177\000\000\000\000\000\000\000\000\000\000x", '\000' <repeats 15 times>"\247, Z\016v\000\000\000\000(\000\000\000\060\000\000\000\200\246\327o\344\177\000\000\300\245\327o\344\177\000\000\n", '\000' <repeats 31 times>"\227"... timestamp = <optimized out> cmd = 0x0 priv = 0x7fe464022500 err = 0x0 __FUNCTION__ = "virLXCProcessStart" __func__ = "virLXCProcessStart" ---Type <return> to continue, or q <return> to quit--- #3 0x00007fe46aa9736e in lxcDomainCreateWithFlags (dom=0x7fe4580008c0, flags=<optimized out>) at lxc/lxc_driver.c:1054 driver = 0x7fe4640bd340 vm = 0x7fe4640c1610 event = 0x0 ret = -1 __FUNCTION__ = "lxcDomainCreateWithFlags" On Mon, Jul 15, 2013 at 7:06 AM, Dennis Jenkins <dennis.jenkins...@gmail.com > wrote: > > On Mon, Jul 15, 2013 at 3:18 AM, Michal Privoznik <mpriv...@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 running libvirt on my Gentoo development server, built from portage. > Instead of tinkering with portage and rebuilding libvirt, I thought that I > would just try the latest pull from git. "./configure" fails, unable to > find an input file. I'll try again, using the same source tarball as > listed in Gentoo's ebuild. > > ostara libvirt # CFLAGS="-O0 -g3" ./configure --with-lxc > > config.status: creating libvirt.pc > config.status: creating libvirt.spec > config.status: error: cannot find input file: `mingw32-libvirt.spec.in' > > >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users