qemu-kvm 0.12.2 VNC segfault
I've just had a segfault from one of the qemu-kvm virtual machines we run. This is qemu-kvm 0.12.2 running with the in-kernel kvm modules on linux 2.6.32.7 on a dual quad-core Xeon E5420 machine, with ksm enabled.
The backtrace looks like
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c:908 #1 0x00000000004c015b in vnc_refresh (opaque=<value optimized out>) at vnc.c:2305 #2 0x0000000000405f50 in qemu_run_timers (ptimer_head=0x836cc0, current_time=1606536889) at /packages/qemu-kvm-0.12/src-gktOMQ/vl.c:1127 #3 0x0000000000408edf in main_loop_wait (timeout=1000) at /packages/qemu-kvm-0.12/src-gktOMQ/vl.c:4036 #4 0x0000000000421d7a in kvm_main_loop () at /packages/qemu-kvm-0.12/src-gktOMQ/qemu-kvm.c:2121 #5 0x000000000040b755 in main (argc=<value optimized out>, argv=0x7fffcc2fa1b8, envp=<value optimized out>) at /packages/qemu-kvm-0.12/src-gktOMQ/vl.c:4209
and the segfault itself is rather puzzling.
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c:908
908 if (vs->need_update && vs->csock != -1) {
(gdb) p vs
$1 = (VncState *) 0x83f0
(gdb) p *vs
Cannot access memory at address 0x83f0
The call site in vnc_refresh() looks like:
vs = vd->clients;
while (vs != NULL) {
rects += vnc_update_client(vs, has_dirty);
vs = vs->next;
}but when I go up a stack frame and look at the vd over which this loop would be iterating:
(gdb) up
#1 0x00000000004c015b in vnc_refresh (opaque=<value optimized out>) at vnc.c:2305
2305 rects += vnc_update_client(vs, has_dirty);
(gdb) p *vd->clients
$2 = {csock = 17, ds = 0x19b2760, dirty = {{0, 0, 0, 0} <repeats 293 times>, {50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {50331648, 0, 0, 0}, {0, 0, 0, 0} <repeats 1742 times>}, vd = 0x1ef60b0, need_update = 0, force_update = 0, features = 0, absolute = 0, last_x = -1, last_y = -1, vnc_encoding = 0, tight_quality = 0 '\0', tight_compression = 0 '\0', major = 0, minor = 0, challenge = '\0' <repeats 15 times>, output = {capacity = 1036, offset = 0, buffer = 0x1ec7420 "RFB 003.008\n¦\177"}, input = {capacity = 0, offset = 0, buffer = 0x0}, write_pixels = 0, send_hextile_tile = 0, clientds = {flags = 0 '\0', width = 0, height = 0, linesize = 0, data = 0x0, pf = {bits_per_pixel = 0 '\0', bytes_per_pixel = 0 '\0', depth = 0 '\0', rmask = 0, gmask = 0, bmask = 0, amask = 0, rshift = 0 '\0', gshift = 0 '\0', bshift = 0 '\0', ashift = 0 '\0', rmax = 0 '\0', gmax = 0 '\0', bmax = 0 '\0', amax = 0 '\0', rbits = 0 '\0', gbits = 0 '\0', bbits = 0 '\0', abits = 0 '\0'}}, audio_cap = 0x0, as = {freq = 44100, nchannels = 2, fmt = AUD_FMT_S16, endianness = 0}, read_handler = 0x4bdb30 <protocol_version>, read_handler_expect = 12, modifiers_state = '\0' <repeats 255 times>, zlib = {capacity = 0, offset = 0, buffer = 0x0}, zlib_tmp = {capacity = 0, offset = 0, buffer = 0x0}, zlib_stream = {{next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}}, next = 0x0}
(gdb) p vd->clients.next
$3 = (VncState *) 0x0So the first client in vd is fine, and the next pointer is set to zero, not 0x83f0.
Some sort of race where a client disconnects and is removed from the client list while the vnc_refresh() loop is iterating over it, maybe?
Cheers,
Chris.
Quoted 3 lines · Chris Webb
Some sort of race where a client disconnects and is removed from the client list while the
vnc_refresh()loop is iterating over it, maybe?
Looks like c727a05459, and high time for 0.12.3. Anthony?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 5 lines · Avi Kivity
Quoted 2 lines · Chris Webb
Some sort of race where a client disconnects and is removed from the client list while the
vnc_refresh()loop is iterating over it, maybe?Looks like
c727a05459, and high time for 0.12.3. Anthony?
Ah yes, looks like this was exactly the case that commit was trying to prevent. Thanks!
Best wishes,
Chris.
Quoted 5 lines · Avi Kivity
Quoted 2 lines · Chris Webb
Some sort of race where a client disconnects and is removed from the client list while the
vnc_refresh()loop is iterating over it, maybe?Looks like
c727a05459, and high time for 0.12.3. Anthony?
Indeed.
Regards,
Anthony Liguori
Another VNC crash, qemu-kvm-0.12.3
We've just seen another VNC related qemu-kvm crash, this time an arithmetic exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
[...]
1423 if (vs->absolute) {
1424 kbd_mouse_event(x * 0x7FFF / (ds_get_width(vs->ds) - 1),
1425 y * 0x7FFF / (ds_get_height(vs->ds) - 1),
1426 dz, buttons);
1427 } else if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE)) {
1428 x -= 0x7FFF;
[...]and sure enough:
(gdb) p vs->ds->surface->width
$1 = 9
(gdb) p vs->ds->surface->height
$2 = 1
What a 9x1 display surface is doing on this guest is a mystery to me, but you definitely can't divide by one less than its height!
(gdb) p *vs
$3 = {csock = 19, ds = 0x1c60fa0, dirty = {{4294967295, 4294967295, 4294967295, 4294967295,
4294967295} <repeats 2048 times>}, vd = 0x26a0110, need_update = 1, force_update = 0, features = 67,
absolute = 1, last_x = -1, last_y = -1, vnc_encoding = 5, tight_quality = 9 '\t', tight_compression = 9 '\t',
major = 3, minor = 8, challenge = "¹{\177\226\200kÕjéPñÄA¤o)", output = {capacity = 925115, offset = 0,
buffer = 0x28ba4b0 ""}, input = {capacity = 5120, offset = 6, buffer = 0x28b90a0 "\005"},
write_pixels = 0x4bb9e0 <vnc_write_pixels_generic>, send_hextile_tile = 0x4bcdf0 <send_hextile_tile_generic_32>,
clientds = {flags = 0 '\0', width = 800, height = 600, linesize = 3200, data = 0x7fcd00ab6010 "", pf = {
bits_per_pixel = 32 ' ', bytes_per_pixel = 4 '\004', depth = 24 '\030', rmask = 0, gmask = 0, bmask = 0,
amask = 0, rshift = 16 '\020', gshift = 8 '\b', bshift = 0 '\0', ashift = 24 '\030', rmax = 255 'ÿ',
gmax = 255 'ÿ', bmax = 255 'ÿ', amax = 255 'ÿ', rbits = 8 '\b', gbits = 8 '\b', bbits = 8 '\b',
abits = 8 '\b'}}, audio_cap = 0x0, as = {freq = 44100, nchannels = 2, fmt = AUD_FMT_S16, endianness = 0},
read_handler = 0x4beac0 <protocol_client_msg>, read_handler_expect = 6, modifiers_state = '\0' <repeats 255 times>,
zlib = {capacity = 0, offset = 0, buffer = 0x0}, zlib_tmp = {capacity = 0, offset = 0, buffer = 0x0},
zlib_stream = {{next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0,
state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0,
avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0,
zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0,
next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0,
data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0,
adler = 0, reserved = 0}}, next = 0x0} (gdb) p *vs->ds
$4 = {surface = 0x1c81f40, opaque = 0x26a0110, gui_timer = 0x0, allocator = 0x8199d0, listeners = 0x1c95fa0,
mouse_set = 0, cursor_define = 0, next = 0x0}
(gdb) p *vs->ds->surface
$5 = {flags = 2 '\002', width = 9, height = 1, linesize = 36, data = 0x7fcd00ab6010 "", pf = {
bits_per_pixel = 32 ' ', bytes_per_pixel = 4 '\004', depth = 24 '\030', rmask = 16711680, gmask = 65280,
bmask = 255, amask = 0, rshift = 16 '\020', gshift = 8 '\b', bshift = 0 '\0', ashift = 24 '\030', rmax = 255 'ÿ',
gmax = 255 'ÿ', bmax = 255 'ÿ', amax = 255 'ÿ', rbits = 8 '\b', gbits = 8 '\b', bbits = 8 '\b', abits = 8 '\b'}}Cheers,
Chris.
Re: Another VNC crash, qemu-kvm-0.12.3
Quoted 14 lines · Chris Webb
We've just seen another VNC related qemu-kvm crash, this time an arithmetic exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
[...] 1423 if (vs->absolute) { 1424 kbd_mouse_event(x * 0x7FFF / (ds_get_width(vs->ds) - 1), 1425 y * 0x7FFF / (ds_get_height(vs->ds) - 1), 1426 dz, buttons); 1427 } else if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE)) { 1428 x -= 0x7FFF; [...]and sure enough:
Quoted 8 lines
(gdb) p vs->ds->surface->width $1 = 9 (gdb) p vs->ds->surface->height $2 = 1What a 9x1 display surface is doing on this guest is a mystery to me, but you definitely can't divide by one less than its height!
Can you reproduce this reliably? If so, what's the procedure?
BTW, I'd suggest filing this at http://bugs.launchpad.net/qemu
Regards,
Anthony Liguori
Quoted 41 lines
(gdb) p *vs $3 = {csock = 19, ds = 0x1c60fa0, dirty = {{4294967295, 4294967295, 4294967295, 4294967295, 4294967295}<repeats 2048 times>}, vd = 0x26a0110, need_update = 1, force_update = 0, features = 67, absolute = 1, last_x = -1, last_y = -1, vnc_encoding = 5, tight_quality = 9 '\t', tight_compression = 9 '\t', major = 3, minor = 8, challenge = "¹{\177\226\200kÕjéPñÄA¤o)", output = {capacity = 925115, offset = 0, buffer = 0x28ba4b0 ""}, input = {capacity = 5120, offset = 6, buffer = 0x28b90a0 "\005"}, write_pixels = 0x4bb9e0<vnc_write_pixels_generic>, send_hextile_tile = 0x4bcdf0<send_hextile_tile_generic_32>, clientds = {flags = 0 '\0', width = 800, height = 600, linesize = 3200, data = 0x7fcd00ab6010 "", pf = { bits_per_pixel = 32 ' ', bytes_per_pixel = 4 '\004', depth = 24 '\030', rmask = 0, gmask = 0, bmask = 0, amask = 0, rshift = 16 '\020', gshift = 8 '\b', bshift = 0 '\0', ashift = 24 '\030', rmax = 255 'ÿ', gmax = 255 'ÿ', bmax = 255 'ÿ', amax = 255 'ÿ', rbits = 8 '\b', gbits = 8 '\b', bbits = 8 '\b', abits = 8 '\b'}}, audio_cap = 0x0, as = {freq = 44100, nchannels = 2, fmt = AUD_FMT_S16, endianness = 0}, read_handler = 0x4beac0<protocol_client_msg>, read_handler_expect = 6, modifiers_state = '\0'<repeats 255 times>, zlib = {capacity = 0, offset = 0, buffer = 0x0}, zlib_tmp = {capacity = 0, offset = 0, buffer = 0x0}, zlib_stream = {{next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}}, next = 0x0} (gdb) p *vs->ds $4 = {surface = 0x1c81f40, opaque = 0x26a0110, gui_timer = 0x0, allocator = 0x8199d0, listeners = 0x1c95fa0, mouse_set = 0, cursor_define = 0, next = 0x0} (gdb) p *vs->ds->surface $5 = {flags = 2 '\002', width = 9, height = 1, linesize = 36, data = 0x7fcd00ab6010 "", pf = { bits_per_pixel = 32 ' ', bytes_per_pixel = 4 '\004', depth = 24 '\030', rmask = 16711680, gmask = 65280, bmask = 255, amask = 0, rshift = 16 '\020', gshift = 8 '\b', bshift = 0 '\0', ashift = 24 '\030', rmax = 255 'ÿ', gmax = 255 'ÿ', bmax = 255 'ÿ', amax = 255 'ÿ', rbits = 8 '\b', gbits = 8 '\b', bbits = 8 '\b', abits = 8 '\b'}}Cheers,
Chris.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Another VNC crash, qemu-kvm-0.12.3
Quoted 20 lines · Anthony Liguori
Quoted 19 lines · Chris Webb
We've just seen another VNC related qemu-kvm crash, this time an arithmetic exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
[...] 1423 if (vs->absolute) { 1424 kbd_mouse_event(x * 0x7FFF / (ds_get_width(vs->ds) - 1), 1425 y * 0x7FFF / (ds_get_height(vs->ds) - 1), 1426 dz, buttons); 1427 } else if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE)) { 1428 x -= 0x7FFF; [...]and sure enough:
(gdb) p
vs->ds->surface->width
$1 = 9
(gdb) pvs->ds->surface->height
$2 = 1
Quoted 4 lines
Quoted 2 lines
What a 9x1 display surface is doing on this guest is a mystery to me, but you definitely can't divide by one less than its height!
Can you reproduce this reliably? If so, what's the procedure?
No, I'm afraid not, although I have had a thorough play myself with a variety of VNC clients in an attempt to reproduce.
The background here is that we're running a public hosting service where customers can install and run their own OSes on their own qemu-kvm virtual machines. I don't even know what VNC client (if any) was connected at the time. I only see the core dump if the qemu-kvm crashes.
Of course, if the screen width or height is 1, it doesn't really matter what the value of the mouse position for the click is, so something as simple as
vnc.c +4 -2
@@ -1421,8 +1421,10 @@ dz =1 ;if (vs->absolute) { -kbd_mouse_event (x *0x7FFF / (ds_get_width (vs->ds) -1 ), - y *0x7FFF / (ds_get_height (vs->ds) -1 ), +kbd_mouse_event (ds_get_width (vs->ds) >1 ? + x *0x7FFF / (ds_get_width (vs->ds) -1 ) :0x4000 , +ds_get_height (vs->ds) >1 ? + y *0x7FFF / (ds_get_height (vs->ds) -1 ) :0x4000 , dz, buttons); }else if (vnc_has_feature (vs,VNC_FEATURE_POINTER_TYPE_CHANGE )) { x -=0x7FFF ;
will fix the symptom: the division by zero. The underlying cause of a 9x1 display surface is a bit mysterious though.
Cheers,
Chris.
Re: [Qemu-devel] Re: Another VNC crash, qemu-kvm-0.12.3
Quoted 55 lines · Chris Webb
Quoted 20 lines · Anthony Liguori
Quoted 19 lines · Chris Webb
We've just seen another VNC related qemu-kvm crash, this time an arithmetic exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
[...]
1423 if (vs->absolute) {
1424 kbd_mouse_event(x *0x7FFF/ (ds_get_width(vs->ds)- 1),
1425 y *0x7FFF/ (ds_get_height(vs->ds)- 1),
1426 dz, buttons);
1427 } else if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE)) {
1428 x -=0x7FFF;
[...]and sure enough:
(gdb) p
vs->ds->surface->width
$1 = 9
(gdb) pvs->ds->surface->height
$2 = 1Quoted 4 lines
Quoted 2 lines
What a 9x1 display surface is doing on this guest is a mystery to me, but you definitely can't divide by one less than its height!
Can you reproduce this reliably? If so, what's the procedure?
No, I'm afraid not, although I have had a thorough play myself with a variety of VNC clients in an attempt to reproduce.
The background here is that we're running a public hosting service where customers can install and run their own OSes on their own qemu-kvm virtual machines. I don't even know what VNC client (if any) was connected at the time. I only see the core dump if the qemu-kvm crashes.
Of course, if the screen width or height is 1, it doesn't really matter what the value of the mouse position for the click is, so something as simple as
vnc.c +4
-2@@ -1421,8 +1421,10 @@ dz =1 ;if (vs->absolute) { -kbd_mouse_event (x *0x7FFF / (ds_get_width (vs->ds) -1 ), - y *0x7FFF / (ds_get_height (vs->ds) -1 ), +kbd_mouse_event (ds_get_width (vs->ds) >1 ? + x *0x7FFF / (ds_get_width (vs->ds) -1 ) :0x4000 , +ds_get_height (vs->ds) >1 ? + y *0x7FFF / (ds_get_height (vs->ds) -1 ) :0x4000 , dz, buttons); }else if (vnc_has_feature (vs,VNC_FEATURE_POINTER_TYPE_CHANGE )) { x -=0x7FFF ;
Quoted 2 lines
will fix the symptom: the division by zero. The underlying cause of a 9x1 display surface is a bit mysterious though.
Is it? When booting the screen gets resized to something like 9x1 for a few ms. Try putting debug code in the resize callback - you'll see it.
Alex
Re: [Qemu-devel] Re: Another VNC crash, qemu-kvm-0.12.3
Quoted 22 lines · Alexander Graf
Quoted 20 lines · Chris Webb
Of course, if the screen width or height is 1, it doesn't really matter what the value of the mouse position for the click is, so something as simple as
vnc.c +4
-2@@ -1421,8 +1421,10 @@ dz =1 ;if (vs->absolute) { -kbd_mouse_event (x *0x7FFF / (ds_get_width (vs->ds) -1 ), - y *0x7FFF / (ds_get_height (vs->ds) -1 ), +kbd_mouse_event (ds_get_width (vs->ds) >1 ? + x *0x7FFF / (ds_get_width (vs->ds) -1 ) :0x4000 , +ds_get_height (vs->ds) >1 ? + y *0x7FFF / (ds_get_height (vs->ds) -1 ) :0x4000 , dz, buttons); }else if (vnc_has_feature (vs,VNC_FEATURE_POINTER_TYPE_CHANGE )) { x -=0x7FFF ;
Quoted 5 lines
Quoted 2 lines
will fix the symptom: the division by zero. The underlying cause of a 9x1 display surface is a bit mysterious though.
Is it? When booting the screen gets resized to something like 9x1 for a few ms. Try putting debug code in the resize callback - you'll see it.
Ah, okay. In that case, this patch could well be the correct fix rather than just a work-around. I'll have a look for any other places in vnc.c that might do a similar division-by-zero for small screen sizes at the same point.
Best wishes,
Chris.
PATCH 1/1 Fix SIGFPE for vnc display of width/height = 1
During boot, the screen gets resized to height 1 and a mouse click at this point will cause a division by zero when calculating the absolute pointer position from the pixel (x, y). Return a click in the middle of the screen instead in this case.
--- vnc.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
vnc.c +4 -2
@@ -1457,8 +1457,10 @@ static void pointer_event(VncState *vs, int button_mask, int x, int y) dz =1 ;if (vs->absolute) { -kbd_mouse_event (x *0x7FFF / (ds_get_width (vs->ds) -1 ), - y *0x7FFF / (ds_get_height (vs->ds) -1 ), +kbd_mouse_event (ds_get_width (vs->ds) >1 ? + x *0x7FFF / (ds_get_width (vs->ds) -1 ) :0x4000 , +ds_get_height (vs->ds) >1 ? + y *0x7FFF / (ds_get_height (vs->ds) -1 ) :0x4000 , dz, buttons); }else if (vnc_has_feature (vs,VNC_FEATURE_POINTER_TYPE_CHANGE )) { x -=0x7FFF ;
Signature · 1 line
1.7.0.1
Re: [Qemu-devel] [PATCH] Fix SIGFPE for vnc display of width/height = 1
Quoted 4 lines · Chris Webb
During boot, the screen gets resized to height 1 and a mouse click at this point will cause a division by zero when calculating the absolute pointer position from the pixel (x, y). Return a click in the middle of the screen instead in this case.
I think this probably ought to be a candidate for 0.12-stable too. We're seeing these crashes for real from time-to-time so it's not just a theoretical problem.
Cheers,
Chris.
Anthony Liguori
AppliedRe: [Qemu-devel] [PATCH] Fix SIGFPE for vnc display of width/height = 1
In reply to Chris WebbQuoted 7 lines · Chris Webb
During boot, the screen gets resized to height 1 and a mouse click at this point will cause a division by zero when calculating the absolute pointer position from the pixel (x, y). Return a click in the middle of the screen instead in this case.
Signed-off-by Chris Webb<[email protected]>
Applied. Thanks.
Regards,
Anthony Liguori
Quoted 22 lines
--- vnc.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)vnc.c +4
-2@@ -1457,8 +1457,10 @@ static void pointer_event(VncState *vs, int button_mask, int x, int y) dz =1 ;if (vs->absolute) { -kbd_mouse_event (x *0x7FFF / (ds_get_width (vs->ds) -1 ), - y *0x7FFF / (ds_get_height (vs->ds) -1 ), +kbd_mouse_event (ds_get_width (vs->ds)>1 ? + x *0x7FFF / (ds_get_width (vs->ds) -1 ) :0x4000 , +ds_get_height (vs->ds)>1 ? + y *0x7FFF / (ds_get_height (vs->ds) -1 ) :0x4000 , dz, buttons); }else if (vnc_has_feature (vs,VNC_FEATURE_POINTER_TYPE_CHANGE )) { x -=0x7FFF ;
Re: [Qemu-devel] [PATCH] Fix SIGFPE for vnc display of width/height = 1
Quoted 9 lines · Anthony Liguori
Quoted 8 lines · Chris Webb
During boot, the screen gets resized to height 1 and a mouse click at this
point will cause a division by zero when calculating the absolute pointer
position from the pixel (x, y). Return a click in the middle of the screen
instead in this case.
Quoted 3 lines
Quoted 2 lines
Signed-off-by Chris Webb<[email protected]>Applied. Thanks.
Also queued it to stable?
Alex