<div dir="ltr"><div>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.<br>
<br></div><div>Line #442 for me is the one containing the "STREQ" macro:<br><br> virObjectLock(mgr);<br> for (i = 0; i < vm->nseclabels; i++) {<br> for (j = 0; sec_managers[j]; j++)<br> if (STREQ(vm->seclabels[i]->model, sec_managers[j]->drv->name))<br>
break;<br><br></div><div><br></div><div>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.<br>
</div><div><br><br></div><div><div><br>(gdb) bt full<br>#0 0x00007fe4750c5d76 in __strcmp_sse42 () from /lib64/libc.so.6<br>No symbol table info available.<br>#1 0x00007fe47578ad31 in virSecurityManagerGenLabel (mgr=0x7fe4640acfa0, vm=0x7fe4640c5e40) at security/security_manager.c:442<br>
ret = -1<br> i = <optimized out><br> j = <optimized out><br> sec_managers = 0x7fe458001880<br> seclabel = <optimized out><br> generated = false<br> __FUNCTION__ = "virSecurityManagerGenLabel"<br>
__func__ = "virSecurityManagerGenLabel"<br>#2 0x00007fe46aa92979 in virLXCProcessStart (conn=0x7fe460000a80, driver=0x7fe4640bd340, vm=0x7fe4640c1610, autoDestroy=false,<br> reason=VIR_DOMAIN_RUNNING_BOOTED) at lxc/lxc_process.c:1144<br>
rc = -1<br> r = <optimized out><br> nttyFDs = 1<br> ttyFDs = 0x7fe458001790<br> i = <optimized out><br> logfile = 0x7fe458000ad0 "/var/log/libvirt/lxc/dwj-hfax-dev.log"<br>
logfd = -1<br> nveths = 0<br> veths = 0x0<br> handshakefds = {-1, -1}<br> pos = -1<br> 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"...<br>
timestamp = <optimized out><br> cmd = 0x0<br> priv = 0x7fe464022500<br> err = 0x0<br> __FUNCTION__ = "virLXCProcessStart"<br> __func__ = "virLXCProcessStart"<br>
---Type <return> to continue, or q <return> to quit---<br>#3 0x00007fe46aa9736e in lxcDomainCreateWithFlags (dom=0x7fe4580008c0, flags=<optimized out>) at lxc/lxc_driver.c:1054<br> driver = 0x7fe4640bd340<br>
vm = 0x7fe4640c1610<br> event = 0x0<br> ret = -1<br> __FUNCTION__ = "lxcDomainCreateWithFlags"<br><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 7:06 AM, Dennis Jenkins <span dir="ltr"><<a href="mailto:dennis.jenkins.75@gmail.com" target="_blank">dennis.jenkins.75@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 3:18 AM, Michal Privoznik <span dir="ltr"><<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
</div>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.<br>
<br></blockquote></div><br><br></div></div><div class="gmail_extra">I'll try.<br><br>I'm not sure why GDB failed to list line numbers in the backtrace. I will recompile libvirt with "-O0 -g3" and try again.<br>
<br>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.<br>
</div><div class="gmail_extra"><br>ostara libvirt # CFLAGS="-O0 -g3" ./configure --with-lxc<br><br>config.status: creating libvirt.pc<br>config.status: creating libvirt.spec<br>config.status: error: cannot find input file: `<a href="http://mingw32-libvirt.spec.in" target="_blank">mingw32-libvirt.spec.in</a>'<br>
<br><br></div></div>
</blockquote></div><br></div>