Description of problem: The crash happens when I try to start a spice session from the RHEV-M webinterface Version-Release number of selected component: virt-viewer-2.0-1.fc22 Additional info: reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: remote-viewer --spice-controller crash_function: _g_log_abort executable: /usr/bin/remote-viewer global_pid: 13537 kernel: 4.0.0-1.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (4 frames) #0 _g_log_abort at gmessages.c:315 #3 do_pre_parse_initialization at gtkmain.c:644 #4 pre_parse_hook at gtkmain.c:752 #5 g_option_context_parse at goption.c:1925
Created attachment 1020190 [details] File: backtrace
Created attachment 1020191 [details] File: build_ids
Created attachment 1020192 [details] File: cgroup
Created attachment 1020193 [details] File: core_backtrace
Created attachment 1020194 [details] File: dso_list
Created attachment 1020195 [details] File: environ
Created attachment 1020196 [details] File: limits
Created attachment 1020197 [details] File: maps
Created attachment 1020198 [details] File: mountinfo
Created attachment 1020199 [details] File: namespaces
Created attachment 1020200 [details] File: open_fds
Created attachment 1020201 [details] File: proc_pid_status
Created attachment 1020202 [details] File: var_log_messages
The console shows this error message: (remote-viewer:13700): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
I assume this happens too if you start remote-viewer manually from a terminal? (just type 'remote-viewer'). does 'ldd /usr/bin/remote-viewer |grep gtk' show it linking with both gtk2 and gtk3 ?
Ah, the backtrace shows that something is indeed bringing gtk2 in :( /usr/lib64/libcacard.so.0.0.0 caused issues in the past, dunno if it's the culprit this time
When I execute remote-viewer manually or indicate in the RHEV-M webinterface that the native client should be used (instead of the browser plugin) it works fine. It seems to be limited to the XPI plugin $ ldd /usr/bin/remote-viewer |grep gtk libgtk-vnc-2.0.so.0 => /lib64/libgtk-vnc-2.0.so.0 (0x00007f01aa2b0000) libspice-client-gtk-3.0.so.4 => /lib64/libspice-client-gtk-3.0.so.4 (0x00007f01a93e3000) libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f01a8af9000) This is on Fedora 22 btw
What does 'update-alternatives --display spice-xpi-client' point to? Is it (a symlink to) /usr/bin/remote-viewer or something else?
$ ls -al /usr/libexec/spice-xpi-client lrwxrwxrwx. 1 root root 34 21 mrt 19:04 /usr/libexec/spice-xpi-client -> /etc/alternatives/spice-xpi-client $ alternatives --config spice-xpi-client Er is 1 programma die 'spice-xpi-client' levert. Selectie Commando ----------------------------------------------- *+ 1 /usr/libexec/spice-xpi-client-remote-viewer <enter> om de huidige selectie te bewaren[+], of type een selectie nummer: ^C
(LC_ALL=C before the command could be helpful though it does not matter much here). What is /usr/libexec/spice-xpi-client-remote-viewer pointing to or what is it running? I'm trying to make sure this is actually running /usr/bin/remote-viewer and not something else.
$ ls -la /usr/libexec/spice-xpi-client-remote-viewer -rwxr-xr-x. 1 root root 214 12 jan 19:17 /usr/libexec/spice-xpi-client-remote-viewer $ rpm --query --whatprovides /usr/libexec/spice-xpi-client-remote-viewer virt-viewer-2.0-1.fc22.x86_64 Thus the xpi-client points to virt-viewer instead of remote-viewer
Scratch that last comment, /usr/libexec/spice-xpi-client-remote-viewer is a shell script (provided by the virt-viewer package) which calls remote-viewer
This is what I was about to mention. As the shell script is running 'remote-viewer' and not '/usr/bin/remote-viewer', do you have another remote-viewer binary anywhere else on your system?
# find / -name remote-viewer 2> /dev/null /usr/bin/remote-viewer I also verified my bash profile and there is no alias set named 'remote-viewer'
I just tried to diff the list of loaded libraries mentioned here in the dso_list file with a list generated by running remote-viewer normally (using lsof). In this diff I noticed that the library libmozgtk2.so also gets loaded when using the XPI plugin. This library (/usr/lib64/firefox/libmozgtk2.so) pulls in GTK2 so that might explain the error
Yup, it does explain the error. Adding "unset LD_PRELOAD" at the beginning of /usr/libexec/spice-xpi-client fixes the crash.
Nice catch, the environ file which is attached to this bug indeed contains a LD_PRELOAD=/usr/lib64/firefox/libmozgtk2.so. This isn't something I have set myself so I guess it is firefox itself which is to blame here. My guess is that other GTK3 based XPI plugins will be affected by this as well. We could work around it for now by adding an 'unset LD_PRELOAD' to the /usr/libexec/spice-xpi-client script but that sounds more like a hack to me than the right solution. Perhaps we should reassign this bug to the firefox product so we can found out their opinion on this?
Hmm the situation seems complicated/ugly http://emilio.pozuelo.org/posts/75 This seems to be done on purpose, in which case unsetting LD_PRELOAD in our wrapper script may be the best fix.
From what I understand from that blog posting is that the LD_PRELOAD override is only needed for starting up the plugin-container itself. If that really is the case then the plugin-container itself should also sanitize/clean up the environment before loading/spawning the requested plugin in question (spice-xpi in this case).
*** Bug 1220899 has been marked as a duplicate of this bug. ***
There's no support of GTK3 based XPI plugins (actually you don't use XPI plugin but NPAPI plugin). The NPAPI supports Gtk2 only.
The plugin itself is not linking with gtk+. It however starts a new process (using g_spawn_async() from glib), and this process happens to be using gtk3. The environment our plugin inherited from plugin-container contains some LD_PRELOAD hack in order to be able the gtk2 flash plugin with gtk3 firefox, and it's this LD_PRELOAD which interacts badly with the process we are trying to spawn.
I sent http://lists.freedesktop.org/archives/spice-devel/2015-May/020003.html upstream.
spice-xpi-2.8.90-7.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/spice-xpi-2.8.90-7.fc22
Package spice-xpi-2.8.90-7.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spice-xpi-2.8.90-7.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9757/spice-xpi-2.8.90-7.fc22 then log in and leave karma (feedback).
spice-xpi-2.8.90-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.