Chris Webb ch...@arachsys.com writes:
With the following applied, VNC connections and disconnections still work
correctly, so it doesn't horribly break anything, but I can't immediately
confirm whether it will cure the rare segfaults as I haven't yet found a
rapid way of reproducing the
Avi Kivity a...@redhat.com writes:
master branch has a patch that fixes a use-after-free when
disconnecting. Unfortunately it doesn't port cleanly to stable-0.10.
I've collected quite a few more core dumps from segfaults of client virtual
machines now, all of which are VNC related and could
Chris Webb ch...@arachsys.com writes:
Avi Kivity a...@redhat.com writes:
I understand it's hard, but it's nearly impossible to work out the
problem from so little data, so please do make the effort to obtain
dumps.
We're trying for this at the moment, but since we can't change the
Chris Webb ch...@arachsys.com writes:
The segfault appears to be a null pointer dereference. ts-clock is NULL
and line 1161 uses ts-clock-type:
(gdb) p ts
$4 = (QEMUTimer *) 0x30d1f30
(gdb) p ts-clock
$5 = (QEMUClock *) 0x0
Sorry, meant to paste this too:
(gdb) p *ts
$1 =
On 08/13/2009 03:23 PM, Chris Webb wrote:
We've been lucky and relatively quickly got a core dump from one of the new
qemu-kvms with the non-zero core file rlimit. A backtrace looks like this:
(gdb) bt
#0 0x004068f7 in qemu_mod_timer (ts=0x30d1f30, expire_time=430489)
at
Avi Kivity a...@redhat.com writes:
csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
Was the guest playing with the display resolution?
Yes, I think in this case there was a vncviewer connected, and the guest had
started booting up into windows, which changes the
Chris Webb ch...@arachsys.com writes:
Avi Kivity a...@redhat.com writes:
csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
Was the guest playing with the display resolution?
Yes, I think in this case there was a vncviewer connected, and the guest had
started
On 08/13/2009 03:45 PM, Chris Webb wrote:
Chris Webbch...@arachsys.com writes:
Avi Kivitya...@redhat.com writes:
csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
Was the guest playing with the display resolution?
Yes, I think in this case there
I have a couple of clusters hosting qemu-kvm virtual machines. One of these
clusters consists of dual quad-core Xeon E5420s (vmx), the other consists of
dual quad-core Barcelona Opterons (svm), and both are running x86-64 Linux
2.6.30.4 with the kvm modules included with the upstream kernel
On 08/12/2009 06:01 PM, Chris Webb wrote:
I have a couple of clusters hosting qemu-kvm virtual machines. One of these
clusters consists of dual quad-core Xeon E5420s (vmx), the other consists of
dual quad-core Barcelona Opterons (svm), and both are running x86-64 Linux
2.6.30.4 with the kvm
10 matches
Mail list logo
