Coverity says:
Result is not floating-point (UNINTENDED_INTEGER_DIVISION)
interger_division: Dividing integer expressions "preferred->width * 100"
and "zoom", and then converting the integer quotient to type double. Any
remainder, or fractional part of the quotient, is ignored.
Coverity says:
You might overrun the 108 byte fixed-size string "addr.sun_path" by
copying "unixsock" without checking the lenght.
Note: This detect has an elevated risk because the source argument is a
paramenter of the current function.
To make clear why configure failed - e.g.:
Package requirements (spice-client-gtk-2.0 >= 0.28) were not met
Requested 'spice-client-gtk-2.0 >= 0.28' but version of spice-client-gtk-2.0 is 0.25
instead of
spice-gtk requested but not found
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1214577
When neither --with-spice-gtk=yes nor --with-spice-gtk=no is used,
spice-gtk is supposed to be automatically enabled/disabled depending
on its availability. However, this is not perfectly working as once
spice-gtk has been detected as available, configure will fail if
spice-protocol or spice-controller are too old. In this case, spice-gtk
support should just be disabled rather than configure failing
The zoom can be changed by resizing the window (VNC / Spice without
the agent). It is necessary to recalculate the zoom level before
changing it, otherwise zoom operations will not work correctly.
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=90582
Under some circumstances (Xfce desktop environment, gtk3 client, RHEL6
guest having two monitors running locally) it is possible to create
a loop of resizing windows. It is caused by size request like 1x1 sent
to the guest. These request are created because _window_queue_resize()
is called when the window is being shown.
To avoid the problem, call gtk_widget_show() after its preferred and
default sizes are set.
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=91405
virt_viewer_events_add_handle() creates a GIOChannel in order to watch the
fd it was given for changes.
virt_viewer_events_remove_handle() is freeing all the resources allocated by
virt_viewer_events_add_handle() except for this GIOChannel. This commit adds
the needed g_io_channel_unref() call to virt_viewer_events_remove_handle()
Based on commit 8e95b8d25a3eee6316aff2f83b0c449aaf10984a from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Trying to remove a disabled timer or handle will cause
virt_viewer_events_remove_{handle,timeout}() to return an error
rather than removing it.
Based on commit 79699d73e6e1b7218e3bd8349d176752f86128b9 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
It's possible to create a handle to watch for file events which do not
watch for any file event. Such a handle can be enabled later with
virt_viewer_events_update_handle() by setting some conditions to watch for.
When a handle is disabled after it has been created,
virt_viewer_events_update_handle() makes sure it removes the corresponding
virt_viewer_events_handle::source IO watch if any was set.
virt_viewer_events_add_handle() will always create a
virt_viewer_events_handle::source IO watch even if the handle is not
watching for any events.
This commit makes consistent by only creating a watch with g_io_add_watch()
when the caller asked to watch for some events.
Based on commit d71c143936a35cd6c3f23ae0cbf7f3215d944051 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
The _event_timeout_remove and _event_handle_remove methods
were holding onto the global lock when invoking the free
callback. This is a violation of the libvirt events API
contract which requires free callbacks to be invoked in
a re-entrant safe context.
Based on commit dd17c3cc587c73a8c915238f9d9a3e200e89c93f from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
The deletion of libvirt timeouts/watches is done in 2 steps:
- the first step is synchronous and unregisters the timeout/watch
from glib mainloop
- the second step is asynchronous and triggered from the first step.
It releases the memory used for bookkeeping for the timeout/watch
being deleted
This is done this way to avoid some possible deadlocks when
reentering the sync callback while freeing the memory associated
with the timeout/watch.
However, it's possible to call gvir_event_update_handle after
gvir_event_remove_handle but before _event_handle_remove does
the final cleanup. When this happen, _update_handle will reregister
the handle with glib mainloop, and bad things will happen when
a glib callback is triggered for this event after _event_handle_remove
has freed the memory associated with this handle watch.
This commit marks the timeouts and watches as removed in the
synchronous _remove callback and makes sure removed timeouts/watches
are ignored in _update callbacks.
Based on commit 3e73e0cee977fb20dd29db3ccfe85b00cc386c43 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Timeout and watch deletion is done from an idle callback. However,
we cannot assume that all libvirt event calls (the callbacks passed
to virEventRegisterImpl) will be done from the mainloop thread. It's
thus possible that a libvirt event call will run a thread while
one of the idle deletion callbacks runs.
Given that the 'handles' and 'timeouts' arrays are shared among all
threads, we need to make sure we hold the 'eventlock' mutex before
modifying them.
Based on commit 924178f6b35735458b37d30303fe7bc753dde0b1 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Based on commit 1fb34633ef3b318ea678b775d5e47debc98d2184 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
In libvirt, it's perfectly possible and widely used to have disabled
timers (timeout=-1) and fire them up 'randomly' with timeout=0.
However, with current mapping into glib mainloop it's not possible
and causing troubles.
Based on commit a40a1732e0d53fcc44b8d348cec97152dafd2b88 from
libvirt-glib.
Original author: Michal Privoznik <mprivozn@redhat.com>
Related to: rhbz#1243228
Since 2.31, g_mutex_new() is deprecated.
Based on commit 2dc7476d32a9e158e688486e8f184c719c53bb4c from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
Otherwise, it will crash next time it goes find()
Backtrace:
(gdb) where
#0 0x00007efcae715095 in g_io_create_watch () from
/lib64/libglib-2.0.so.0
#1 0x00007efcae7150ef in g_io_add_watch_full () from
/lib64/libglib-2.0.so.0
#2 0x00000000004275ba in virt_viewer_events_update_handle
(watch=<optimized out>, events=1) at
virt-viewer-events.c:158
#3 0x00007efcb1a62dce in virNetSocketUpdateIOCallback (sock=0x1e75c00,
events=1) at rpc/virnetsocket.c:1981
#4 0x00007efcb1a50113 in virNetClientIOUpdateCallback
(client=<optimized out>, enableCallback=<optimized out>) at
rpc/virnetclient.c:1639
#5 0x00007efcb1a50f82 in virNetClientIO (thiscall=0x20e0170,
client=0x1f2e060) at rpc/virnetclient.c:1793
#6 virNetClientSendInternal (client=client@entry=0x1f2e060,
msg=msg@entry=0x20e0100,
expectReply=expectReply@entry=false, nonBlock=nonBlock@entry=true) at
rpc/virnetclient.c:1962
#7 0x00007efcb1a52413 in virNetClientSendNonBlock (client=0x1f2e060,
msg=msg@entry=0x20e0100) at
rpc/virnetclient.c:2036
#8 0x00007efcb1a5243d in virNetClientKeepAliveSendCB (opaque=<optimized
out>, msg=0x20e0100) at
rpc/virnetclient.c:293
#9 0x00007efcb1a5ba02 in virKeepAliveTimer (timer=<optimized out>,
opaque=0x20d3d00) at rpc/virkeepalive.c:176
#10 0x00000000004272e9 in virt_viewer_events_dispatch_timeout
(opaque=0x1e6cd30) at virt-viewer-events.c:233
#11 0x00007efcae7231b3 in g_timeout_dispatch () from
/lib64/libglib-2.0.so.0
#12 0x00007efcae72279a in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#13 0x00007efcae722ae8 in g_main_context_iterate.isra.24 () from
/lib64/libglib-2.0.so.0
#14 0x00007efcae722dba in g_main_loop_run () from
/lib64/libglib-2.0.so.0
#15 0x00007efcb054a045 in gtk_main () from /lib64/libgtk-3.so.0
#16 0x0000000000410a9c in main (argc=1, argv=0x7ffde58a7978) at
virt-viewer-main.c:124
Based on commit cff5f1c46f4b9661e112b85159fb58ae473a9a89 from
libvirt-glib.
Original author: Marc-André Lureau <marcandre.lureau@redhat.com>
Related to: rhbz#1243228
Based on commit 8f8d9ce5238dbcbce40aa04ba55b8c55f97c79c0 from
libvirt-glib.
Original author: Marc-André Lureau <marcandre.lureau@redhat.com>
Related to: rhbz#1243228
Take a global lock whenever changing any event callbacks to ensure
thread safety.
Based on commit f1fe67da2dac6a249f796535b8dbd155d5741ad7 from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
The function virt_viewer_window_resize restricts window to be bigger
than a client's screen. It avoids extending the window to more client's
screens, it causes changes of the zoom level if the guest does not fit
into a screen.
Lets remove virt_viewer_window_resize (its behaviour was introduced
by the commit 6acb3856b6). It will let
the window managers to handle resizing of the window.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1221501https://bugzilla.redhat.com/show_bug.cgi?id=1205804
Instead of building every single source file twice (once for
virt-viewer, and once for remote-viewer), just build them into a
temporary library and link the final executables against that.
The one possible drawback to this approach is that we now use the same
log domain for both executables: 'virt-viewer'. Previously, the
remote-viewer executable used 'remote-viewer' for its log domain.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
The new msitools release includes the necessaries changes for fixing
mingw-virt-viewer build (on fedora22).
These fixes are:
- an updated libvirt.wxi, removing storageencryption.rng file
- a new included libeproxy.wxi, a new dep for gtk3 since its 3.15.3
version.
When starting virt-viewer with the --reconnect switch to a guest that
has a password, if the user cancels the authentication dialog (e.g.
pressing 'Esc'), the window will display "Waiting for guest domain to
restart". Obviously, the domain will never restart because it's already
running.
After this fix, the application will simply exit when the user cancels
authentication, even if the --reconnect switch is used.
There's no reason that we need to ask if the user wants to retry auth
failures for VNC sessions but not ask for spice sessions. If the user
doesn't want to retry, she can simply click 'cancel' when the auth
dialog pops up, just as they do with spice.
When the user cancells an authentication dialog (e.g. by pressing 'Esc',
emit the session-cancelled signal to be consistent with the spice
session implementation.
Now that VNC and Spice both return the same signal on normal
authentication failures ('session-auth-refused'), the
'session-auth-failed' signal is too confusingly similar. Rename it to
-unsupported to make it obvious that it's a different type of
(unrecoverable) error.
The spice session implementation can retry authentication on its own,
whereas the vnc session needs to tear down the session and re-connect in
order to retry a failed authentication. This results in the following
inconsistent behavior:
VNC session:
- emits a 'session-auth-failed' signal when the client does not support
a particular authentication type (i.e.: a non-recoverable error)
Spice session:
- emits a 'session-auth-failed' signal when user enters an incorrect
password, and immediately retries auth internally
VNC session:
- emits a 'session-auth-refused' error when user enters an invalid
password (i.e.: a recoverable error)
Spice Session:
- never emits a 'session-auth-refused' signal
Because of these differences, the VirtViewerApp code to handle authentication
failures is a bit confusing and difficult to maintain. To fix this issue, make
both the spice and VNC sessions emit the same signal when similar errors occur.
We use the new session API added in the last commit to determine whether the
session supports automatic retries so we know how to handle the signal.
The spice session implementation can retry authentication on its own,
whereas the vnc session needs to tear down the session and re-connect in
order to retry a failed authentication. Add API to determine this so
that we can clean up some code related to authentication failures.
Most of the setup (connecting to signals, etc) for the SpiceSession was
done in create_spice_session(), but some was done afterwards in
virt_viewer_session_spice_new(). Consolidate all session configuration
in one place.
In addition to making it easier to maintain, create_spice_session() is
also called in virt_viewer_session_spice_close(). which results in a
spice session that is configured slightly differently than the first
session created in _new(). Consolidating everything in
create_spice_session() avoids that inconsistency.
Recent chooser didn't unselect on loosing focus.
Selecting recent connection, then modifying address in entry and
doubleclicking on the same recent connection caused remote-viewer to
connect to address in the entry,
Recent chooser now unselects on loosing focus, forcing to re-select when
doubleclicking the recent connection, which will now properly set the
address to connect to.
Changed connect dialog from GtkDialog to a GtkWindow.
Added the necessary signals and buttons, to keep the
behaviour of a dialog. (ESC to close, ENTER to submit)
Connect dialog from remote-viewer is now in its own file.
Most other dialog also have their own files.
This will make changing the dialog into a window easier.
Renamed connect_dialog to remote_viewer_connect_dialog.
Enabling hotkeys will trigger a rebuild of the 'send keys' menu
containing the new hotkeys. virt_viewer_app_set_hotkeys() was clearing
and then enabling the hotkeys before parsing the string containing the
new hotkeys. This was causing these hotkeys to be missing from the 'Send
keys' menu when they are set through the spice controller because the
'send keys' menu was rebuilt before the new hotkeys are set.
Resolves: rhbz#1055600
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1146016
Without this parameter the installer will place the start menu icon in the
Admin users path rather than the 'AllUsers'. Unprivileged users are unable
to use the menu to start the remote-viewer.
N.B. Because previous installations mixed Users and PerMachine (AllUsers)
paths, this installation will *NOT* properly upgrade them. They must be
manually uninstalled first.
