10:25 a.m.
regarding
http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
and
https://www.redhat.com/archives/libvir-list/2012-December/msg00935.html
This seems like the problem i'm having... is there a permanent solution for
this?
(i'm using libvirtd with XEN using libxl)
almost every time i shutdown a domain libvirtd segfaults...
1:59 p.m.
On 03/10/2013 09:25 AM, AL13N wrote:
regarding
http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
and
https://www.redhat.com/archives/libvir-list/2012-December/msg00935.html
There have been several fixes to shutdown since December; can you
reproduce the problem with libvirt 1.0.3?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:46 p.m.
Op maandag 11 maart 2013 12:59:08 schreef Eric Blake:
On 03/10/2013 09:25 AM, AL13N wrote:
> regarding
>
> http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
>
> and
>
> https://www.redhat.com/archives/libvir-list/2012-December/msg00935.html
There have been several fixes to shutdown since December; can you
reproduce the problem with libvirt 1.0.3?
hmm, i'll try and find out...
1:31 p.m.
Op maandag 11 maart 2013 12:59:08 schreef Eric Blake:
On 03/10/2013 09:25 AM, AL13N wrote:
> regarding
>
> http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
>
> and
>
> https://www.redhat.com/archives/libvir-list/2012-December/msg00935.html
There have been several fixes to shutdown since December; can you
reproduce the problem with libvirt 1.0.3?
it happens with libvirt 1.0.3 as well... i had a hvm and pv running and
started them both and shut the pv one down and thats when it happened
2:01 p.m.
Op maandag 11 maart 2013 12:59:08 schreef Eric Blake:
On 03/10/2013 09:25 AM, AL13N wrote:
> regarding
>
> http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
>
> and
>
> https://www.redhat.com/archives/libvir-list/2012-December/msg00935.html
There have been several fixes to shutdown since December; can you
reproduce the problem with libvirt 1.0.3?
this is the journalctl output
https://gist.github.com/5164169
12:19 p.m.
On Thu, Mar 14, 2013 at 20:01:16 +0100, AL13N wrote:
Op maandag 11 maart 2013 12:59:08 schreef Eric Blake:
> On 03/10/2013 09:25 AM, AL13N wrote:
> > regarding
> >
> > http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
> >
> > and
> >
> > https://www.redhat.com/archives/libvir-list/2012-December/msg00935.html
>
> There have been several fixes to shutdown since December; can you
> reproduce the problem with libvirt 1.0.3?
this is the journalctl output
https://gist.github.com/5164169
Thanks, but debug logs without a backtrace are not usually very helpful
in case of a segfault. Could you setup your system to store libvirtd's
core once it crashes, make sure you have all required debuginfo symbols
installed, and use gdb to get the backtrace using
``thread apply all backtrace'' command?
Jirka
1:22 p.m.
Op maandag 18 maart 2013 18:19:51 schreef Jiri Denemark:
On Thu, Mar 14, 2013 at 20:01:16 +0100, AL13N wrote:
> Op maandag 11 maart 2013 12:59:08 schreef Eric Blake:
> > On 03/10/2013 09:25 AM, AL13N wrote:
> > > regarding
> > >
> > > http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
> > >
> > > and
> > >
> > > https://www.redhat.com/archives/libvir-list/2012-December/msg00935.htm
> > > l
> >
> > There have been several fixes to shutdown since December; can you
> > reproduce the problem with libvirt 1.0.3?
>
> this is the journalctl output
>
> https://gist.github.com/5164169
Thanks, but debug logs without a backtrace are not usually very helpful
in case of a segfault. Could you setup your system to store libvirtd's
core once it crashes, make sure you have all required debuginfo symbols
installed, and use gdb to get the backtrace using
``thread apply all backtrace'' command?
Jirka
ok, will try
5:27 p.m.
Op maandag 18 maart 2013 18:19:51 schreef Jiri Denemark:
On Thu, Mar 14, 2013 at 20:01:16 +0100, AL13N wrote:
> Op maandag 11 maart 2013 12:59:08 schreef Eric Blake:
> > On 03/10/2013 09:25 AM, AL13N wrote:
> > > regarding
> > >
> > > http://www.redhat.com/archives/libvir-list/2012-December/msg01365.html
> > >
> > > and
> > >
> > > https://www.redhat.com/archives/libvir-list/2012-December/msg00935.htm
> > > l
> >
> > There have been several fixes to shutdown since December; can you
> > reproduce the problem with libvirt 1.0.3?
>
> this is the journalctl output
>
> https://gist.github.com/5164169
Thanks, but debug logs without a backtrace are not usually very helpful
in case of a segfault. Could you setup your system to store libvirtd's
core once it crashes, make sure you have all required debuginfo symbols
installed, and use gdb to get the backtrace using
``thread apply all backtrace'' command?
here it is...
Thread 12 (Thread 0x7fdeedbac700 (LWP 20534)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146428,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bcb in virThreadPoolWorker (opaque=opaque@entry=0x1123ac0)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 11 (Thread 0x7fdeed3ab700 (LWP 20535)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146428,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bcb in virThreadPoolWorker (opaque=opaque@entry=0x1123c40)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 10 (Thread 0x7fdef0bb2700 (LWP 20528)):
#0 0x00007fdef5b64eaa in __lll_unlock_wake () from /lib64/libpthread.so.0
#1 0x00007fdef5b61b09 in _L_unlock_572 () from /lib64/libpthread.so.0
#2 0x00007fdef5b61aa1 in __pthread_mutex_unlock_usercnt () from
/lib64/libpthread.so.0
#3 0x00007fdee9a734b3 in libxl__ctx_unlock (ctx=<optimized out>) at
libxl_internal.h:2659
#4 libxl__ao_inprogress (ao=ao@entry=0x7fdedc000c60,
file=file@entry=0x7fdee9a7c460 "libxl.c", line=line@entry=1276,
func=func@entry=0x7fdee9a7e310 <__func__.15903> "libxl_domain_destroy")
at libxl_event.c:1627
#5 0x00007fdee9a4d458 in libxl_domain_destroy (ctx=0x7fdee40fe240, domid=38,
ao_how=ao_how@entry=0x0) at libxl.c:1276
#6 0x00007fdee9ca5d22 in libxlVmReap (driver=0x7fdee40c98b0,
vm=0x7fdee40f30f0, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at
libxl/libxl_driver.c:659
#7 0x00007fdee9ca5e49 in libxlDomainDestroyFlags (dom=0x7fdedc000c00,
flags=<optimized out>) at libxl/libxl_driver.c:1799
#8 0x00007fdef5e68417 in virDomainDestroy
(domain=domain@entry=0x7fdedc000c00) at libvirt.c:2224
#9 0x000000000042b9a6 in remoteDispatchDomainDestroy (args=<optimized out>,
rerr=0x7fdef0bb1ca0, client=0x1156a40, server=<optimized out>, msg=<optimized
out>) at remote_dispatch.h:1277
#10 remoteDispatchDomainDestroyHelper (server=<optimized out>,
client=0x1156a40, msg=<optimized out>, rerr=0x7fdef0bb1ca0, args=<optimized
out>, ret=<optimized out>) at remote_dispatch.h:1255
#11 0x00007fdef5ecd1ca in virNetServerProgramDispatchCall (msg=0x1156e10,
client=0x1156a40, server=0x1146220, prog=0x1153560) at
rpc/virnetserverprogram.c:432
#12 virNetServerProgramDispatch (prog=0x1153560,
server=server@entry=0x1146220, client=0x1156a40, msg=0x1156e10) at
rpc/virnetserverprogram.c:305
#13 0x00007fdef5ec82e8 in virNetServerProcessMsg (msg=<optimized out>,
prog=<optimized out>, client=<optimized out>, srv=0x1146220) at
rpc/virnetserver.c:162
#14 virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x1146220) at
rpc/virnetserver.c:183
#15 0x00007fdef5df4b0e in virThreadPoolWorker (opaque=opaque@entry=0x1123ac0)
at util/virthreadpool.c:144
#16 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#17 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#18 0x00007fdef568987d in clone () from /lib64/libc.so.6
#19 0x0000000000000000 in ?? ()
Thread 9 (Thread 0x7fdeee3ad700 (LWP 20533)):
#0 0x00007fdef5b64e0c in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007fdef5b60cb4 in _L_lock_850 () from /lib64/libpthread.so.0
#2 0x00007fdef5b60bb7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007fdef5df46f5 in virMutexLock (m=<optimized out>) at
util/virthreadpthread.c:85
#4 0x00007fdee9c9fac5 in libxlDriverLock (driver=<optimized out>) at
libxl/libxl_driver.c:131
#5 0x00007fdee9ca301a in libxlNumDomains (conn=<optimized out>) at
libxl/libxl_driver.c:1428
#6 0x00007fdef5e677d9 in virConnectNumOfDomains (conn=0x7fdee0000bd0) at
libvirt.c:1900
#7 0x000000000042848f in remoteDispatchNumOfDomains (ret=0x7fdec8000930,
rerr=0x7fdeee3acca0, client=0x1156a40, server=<optimized out>, msg=<optimized
out>) at remote_dispatch.h:10971
#8 remoteDispatchNumOfDomainsHelper (server=<optimized out>,
client=0x1156a40, msg=<optimized out>, rerr=0x7fdeee3acca0, args=<optimized
out>, ret=0x7fdec8000930) at remote_dispatch.h:10952
#9 0x00007fdef5ecd1ca in virNetServerProgramDispatchCall (msg=0x1157510,
client=0x1156a40, server=0x1146220, prog=0x1153560) at
rpc/virnetserverprogram.c:432
#10 virNetServerProgramDispatch (prog=0x1153560,
server=server@entry=0x1146220, client=0x1156a40, msg=0x1157510) at
rpc/virnetserverprogram.c:305
#11 0x00007fdef5ec82e8 in virNetServerProcessMsg (msg=<optimized out>,
prog=<optimized out>, client=<optimized out>, srv=0x1146220) at
rpc/virnetserver.c:162
#12 virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x1146220) at
rpc/virnetserver.c:183
#13 0x00007fdef5df4b0e in virThreadPoolWorker (opaque=opaque@entry=0x1123c40)
at util/virthreadpool.c:144
#14 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#15 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#16 0x00007fdef568987d in clone () from /lib64/libc.so.6
#17 0x0000000000000000 in ?? ()
Thread 8 (Thread 0x7fdeecbaa700 (LWP 20536)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146428,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bcb in virThreadPoolWorker (opaque=opaque@entry=0x1123ac0)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 7 (Thread 0x7fdeeebae700 (LWP 20532)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146428,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bcb in virThreadPoolWorker (opaque=opaque@entry=0x1123ac0)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 6 (Thread 0x7fdeef3af700 (LWP 20531)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146390,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bab in virThreadPoolWorker (opaque=opaque@entry=0x1123c40)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 5 (Thread 0x7fdef6836700 (LWP 20723)):
#0 0x00007fdef5b650ed in read () from /lib64/libpthread.so.0
#1 0x00007fdee9ed73a4 in read (__nbytes=16, __buf=0x7fdec00008d0, __fd=31) at
/usr/include/bits/unistd.h:44
#2 read_all (fd=31, data=0x7fdec00008d0, data@entry=0x20, len=len@entry=16,
nonblocking=nonblocking@entry=0) at xs.c:365
#3 0x00007fdee9ed74b8 in read_message (h=h@entry=0x7fdee40d2a70,
nonblocking=nonblocking@entry=0) at xs.c:1071
#4 0x00007fdee9ed7e29 in read_thread (arg=0x7fdee40d2a70) at xs.c:1137
#5 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#6 0x00007fdef568987d in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 4 (Thread 0x7fdeefbb0700 (LWP 20530)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146390,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bab in virThreadPoolWorker (opaque=opaque@entry=0x1123ac0)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7fdef03b1700 (LWP 20529)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146390,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bab in virThreadPoolWorker (opaque=opaque@entry=0x1123c40)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7fdef13b3700 (LWP 20527)):
#0 0x00007fdef5b625c4 in pthread_cond_wait@(a)GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007fdef5df4766 in virCondWait (c=c@entry=0x1146390,
m=m@entry=0x1146368) at util/virthreadpthread.c:117
#2 0x00007fdef5df4bab in virThreadPoolWorker (opaque=opaque@entry=0x1123c40)
at util/virthreadpool.c:103
#3 0x00007fdef5df4599 in virThreadHelper (data=<optimized out>) at
util/virthreadpthread.c:161
#4 0x00007fdef5b5ed18 in start_thread () from /lib64/libpthread.so.0
#5 0x00007fdef568987d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
#0 0x0000000000000000 in ?? ()
#1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout (ctx=<optimized out>,
for_libxl=0x7fdedc001608) at libxl_event.c:1039
#2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized out>,
timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
#3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
util/vireventpoll.c:450
#4 virEventPollRunOnce () at util/vireventpoll.c:643
#5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at util/virevent.c:273
#6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
rpc/virnetserver.c:1108
#7 0x000000000040c8e0 in main (argc=<optimized out>, argv=<optimized out>) at
libvirtd.c:1481
9:42 a.m.
AL13N wrote:
Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
#0 0x0000000000000000 in ?? ()
#1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout (ctx=<optimized out>,
for_libxl=0x7fdedc001608) at libxl_event.c:1039
#2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized out>,
timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
#3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
util/vireventpoll.c:450
#4 virEventPollRunOnce () at util/vireventpoll.c:643
#5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at util/virevent.c:273
#6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
rpc/virnetserver.c:1108
#7 0x000000000040c8e0 in main (argc=<optimized out>, argv=<optimized out>)
at
libvirtd.c:1481
I received a similar report on #xendevel just yesterday. I'll take a
look at this in the next few days after finishing my current project.
Regards,
Jim
2:42 p.m.
Op woensdag 20 maart 2013 08:42:52 schreef Jim Fehlig:
AL13N wrote:
> Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
> #0 0x0000000000000000 in ?? ()
> #1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout (ctx=<optimized
> out>, for_libxl=0x7fdedc001608) at libxl_event.c:1039
> #2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized out>,
> timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
> #3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
> util/vireventpoll.c:450
> #4 virEventPollRunOnce () at util/vireventpoll.c:643
> #5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at util/virevent.c:273
> #6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
> rpc/virnetserver.c:1108
> #7 0x000000000040c8e0 in main (argc=<optimized out>, argv=<optimized
> out>) at libvirtd.c:1481
I received a similar report on #xendevel just yesterday. I'll take a
look at this in the next few days after finishing my current project.
Regards,
Jim
thanks a lot... did you get somewhere, do you need some more information?
3:08 p.m.
Op woensdag 20 maart 2013 08:42:52 schreef Jim Fehlig:
AL13N wrote:
> Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
> #0 0x0000000000000000 in ?? ()
> #1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout (ctx=<optimized
> out>, for_libxl=0x7fdedc001608) at libxl_event.c:1039
> #2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized out>,
> timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
> #3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
> util/vireventpoll.c:450
> #4 virEventPollRunOnce () at util/vireventpoll.c:643
> #5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at util/virevent.c:273
> #6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
> rpc/virnetserver.c:1108
> #7 0x000000000040c8e0 in main (argc=<optimized out>, argv=<optimized
> out>) at libvirtd.c:1481
I received a similar report on #xendevel just yesterday. I'll take a
look at this in the next few days after finishing my current project.
Regards,
Jim
restesting with libvirt-1.0.4 confirmed that it's still unfixed
8:57 p.m.
AL13N wrote:
Op woensdag 20 maart 2013 08:42:52 schreef Jim Fehlig:
> AL13N wrote:
>
>> Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
>> #0 0x0000000000000000 in ?? ()
>> #1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout (ctx=<optimized
>> out>, for_libxl=0x7fdedc001608) at libxl_event.c:1039
>> #2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized out>,
>> timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
>> #3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
>> util/vireventpoll.c:450
>> #4 virEventPollRunOnce () at util/vireventpoll.c:643
>> #5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at util/virevent.c:273
>> #6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
>> rpc/virnetserver.c:1108
>> #7 0x000000000040c8e0 in main (argc=<optimized out>, argv=<optimized
>> out>) at libvirtd.c:1481
>>
> I received a similar report on #xendevel just yesterday. I'll take a
> look at this in the next few days after finishing my current project.
>
> Regards,
> Jim
>
restesting with libvirt-1.0.4 confirmed that it's still unfixed
I would have been really surprised if it was fixed :).
I did take a few minutes last week to peek at the code, only to realize
it is not a simple fix and requires some investigation. Apologies for
not having time to do this yet. My schedule for the next several weeks
is quite hectic too. I'm adding Bamvor (a SUSE colleague) to the cc
list in case he has some free time to investigate as well.
Regards,
Jim
6:12 a.m.
AL13N wrote:
> Op woensdag 20 maart 2013 08:42:52 schreef Jim Fehlig:
>
>> AL13N wrote:
>>
>>> Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
>>> #0 0x0000000000000000 in ?? ()
>>> #1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout
>>> (ctx=<optimized
>>> out>, for_libxl=0x7fdedc001608) at libxl_event.c:1039
>>> #2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized out>,
>>> timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
>>> #3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
>>> util/vireventpoll.c:450
>>> #4 virEventPollRunOnce () at util/vireventpoll.c:643
>>> #5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at
>>> util/virevent.c:273
>>> #6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
>>> rpc/virnetserver.c:1108
>>> #7 0x000000000040c8e0 in main (argc=<optimized out>,
argv=<optimized
>>> out>) at libvirtd.c:1481
>>>
>> I received a similar report on #xendevel just yesterday. I'll take a
>> look at this in the next few days after finishing my current project.
>>
>> Regards,
>> Jim
>>
>
> restesting with libvirt-1.0.4 confirmed that it's still unfixed
>
I would have been really surprised if it was fixed :).
/me too
I did take a few minutes last week to peek at the code, only to
realize
it is not a simple fix and requires some investigation. Apologies for
not having time to do this yet. My schedule for the next several weeks
is quite hectic too. I'm adding Bamvor (a SUSE colleague) to the cc
list in case he has some free time to investigate as well.
I very well appreciate your help with this. no offense, but the Xen
support for libvirt is pretty basic as it is... imho, it would help if Xen
developers help a bit with the libvirtd XEN driver, and i talked to Citrix
people about this, not sure if it'll work out, but we'll see...
As the Xen package maintainer for Mageia, i would like if libvirt would be
better supported on Xen.
In any case, we are already in version freeze for the coming Mageia 3
release and release freeze is coming soon, it would be awesome if i could
add this patch so that Mageia 3 would have working XEN dom0 + libvirtd
support.
Kind Regards,
Maarten
PS: testing 1.0.4 showed a new bug: if i use the reboot command from the
HVM guest, virt-manager seems to stop refreshing the cpu graph and the
guest doesn't actually seem to reboot (the vnc window can't connect
either). i have to force shutdown it (crashing libvirtd) and booting it up
again...
12:06 p.m.
AL13N wrote:
> AL13N wrote:
>
>> Op woensdag 20 maart 2013 08:42:52 schreef Jim Fehlig:
>>
>>
>>> AL13N wrote:
>>>
>>>
>>>> Thread 1 (Thread 0x7fdef683b800 (LWP 20522)):
>>>> #0 0x0000000000000000 in ?? ()
>>>> #1 0x00007fdee9a72dc7 in libxl_osevent_occurred_timeout
>>>> (ctx=<optimized
>>>> out>, for_libxl=0x7fdedc001608) at libxl_event.c:1039
>>>> #2 0x00007fdee9c9ff87 in libxlTimerCallback (timer=<optimized
out>,
>>>> timer_info=0x7fdedc001730) at libxl/libxl_driver.c:259
>>>> #3 0x00007fdef5dd0f1a in virEventPollDispatchTimeouts () at
>>>> util/vireventpoll.c:450
>>>> #4 virEventPollRunOnce () at util/vireventpoll.c:643
>>>> #5 0x00007fdef5dcf88d in virEventRunDefaultImpl () at
>>>> util/virevent.c:273
>>>> #6 0x00007fdef5ec96c5 in virNetServerRun (srv=0x1146220) at
>>>> rpc/virnetserver.c:1108
>>>> #7 0x000000000040c8e0 in main (argc=<optimized out>,
argv=<optimized
>>>> out>) at libvirtd.c:1481
>>>>
>>>>
>>> I received a similar report on #xendevel just yesterday. I'll take a
>>> look at this in the next few days after finishing my current project.
>>>
>>> Regards,
>>> Jim
>>>
>>>
>> restesting with libvirt-1.0.4 confirmed that it's still unfixed
>>
>>
> I would have been really surprised if it was fixed :).
>
/me too
FYI, Bamvor fixed a remaining (known) race in the libxl driver, which
I've pushed for libvirt 1.0.5
https://www.redhat.com/archives/libvir-list/2013-April/msg01926.html
I still want to cleanup handling of domain destruction events as
mentioned elsewhere in this thread, but that can wait until support for
jobs is added to the driver.
Regards,
Jim
4262
days inactive
4309
days old
13 comments
4 participants
participants (4)
-
AL13N -
Eric Blake -
Jim Fehlig -
Jiri Denemark