[libvirt] segment fault from libvirtmod
Michal Privoznik
mprivozn at redhat.com
Tue Feb 7 10:38:53 UTC 2012
On 06.02.2012 15:59, Michal Privoznik wrote:
> On 06.02.2012 10:08, Guannan Ren wrote:
>>
>>
>> Hi,
>>
>> The Makefile.am in python forget to add probes.o if WITH_DTRACE
>> but after I added it and tried to connect, using
>> libvirt.open("qemu:///system")
>> in python , it reported: "segment fault"
>> I tried to figure out, but failed. If anyone can help this, thanks.
>>
>> The following is the backtrace:
>>
>> #0 0x0000003c62a810a4 in free () from /lib64/libc.so.6
>> #1 0x00007ffff1836f29 in virFree (ptrptr=0x6a6a28) at
>> util/memory.c:310
>> #2 0x00007ffff1849692 in virResetError (err=0x6a6a20) at
>> util/virterror.c:387
>> #3 0x00007ffff13e2761 in do_open (name=0x7ffff7ed6444
>> "qemu:///system", auth=0x0, flags=0) at libvirt.c:1093
>> #4 0x00007ffff13e4d44 in virConnectOpen (name=0x7ffff7ed6444
>> "qemu:///system") at libvirt.c:1350
>> #5 0x00007ffff1824879 in libvirt_virConnectOpen (self=<optimized
>> out>, args=<optimized out>) at libvirt.c:3637
>> #6 0x0000003c652dffbb in PyEval_EvalFrameEx () from
>> /usr/lib64/libpython2.7.so.1.0
>> #7 0x0000003c652e0580 in PyEval_EvalFrameEx () from
>> /usr/lib64/libpython2.7.so.1.0
>> #8 0x0000003c652e15a5 in PyEval_EvalCodeEx () from
>> /usr/lib64/libpython2.7.so.1.0
>> #9 0x0000003c652e16d2 in PyEval_EvalCode () from
>> /usr/lib64/libpython2.7.so.1.0
>> #10 0x0000003c652fb9ec in ?? () from /usr/lib64/libpython2.7.so.1.0
>> #11 0x0000003c652fc7f0 in PyRun_FileExFlags () from
>> /usr/lib64/libpython2.7.so.1.0
>> #12 0x0000003c652fd26f in PyRun_SimpleFileExFlags () from
>> /usr/lib64/libpython2.7.so.1.0
>> #13 0x0000003c6530e745 in Py_Main () from
>> /usr/lib64/libpython2.7.so.1.0
>> #14 0x0000003c62a2169d in __libc_start_main () from /lib64/libc.so.6
>> #15 0x0000000000400651 in _start ()
>>
>> Guannan Ren
>>
>
>
> Running git bisect showed it was caused by
> c700613b8d463212d142c97108b7a2352e23e559. However, I think it only
> exposed the design problem we are facing here.
>
> IMHO problem is when an application tries to call virConnectOpen() (or
> virConnectOpenAuth()) from two concurrent threads. This is what will happen:
>
> 1st thread:
> call virConnectOpen();
> global variable @initialized == zero; thus virInitialize() is called,
> error object is set up (via virErrorInitialize()) which is thread local
> variable. However, @initialized is set to 1 in the first place.
>
> 2nd thread:
> call virConnectOpen() as well;
> @initialized is already set, therefore no thread local variable is set
> and any error report will fail.
>
> Even if I am right, I am not sure how to fix this.
>
> Michal
>
Sorry for mystification. Here's the debug output which shows what's wrong:
http://fpaste.org/6pBs/
However, I am not sure what is causing it.
More information about the libvir-list
mailing list