On 02/07/2012 05:35 PM, Daniel P. Berrange wrote:
On Mon, Feb 06, 2012 at 03:59:19PM +0100, 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.
In a mulithreaded application, you should be calling virInitialize()
explicitly, instead of relying on lazy init. IMHO, the python module
should simply be calling virInitialize at time of import.
Regards,
Daniel
It called virInitialize() in the first place when libvirtmod
is imported.
Right now, I found the pthread_key_t is changed between the time it
is initialized and time to get thread local data using the key. It
probably
point to other location even in single thread.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list