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.75(a)gmail.com
wrote:
On Mon, Jul 15, 2013 at 3:18 AM, Michal Privoznik <mprivozn(a)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'