Bug 1160411 - Eclipse abruptly exits when bluejeans browser plugin is also installed
Summary: Eclipse abruptly exits when bluejeans browser plugin is also installed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse
Version: 21
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alexander Kurtakov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1115174 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-04 18:06 UTC by Carlos O'Donell
Modified: 2015-05-13 07:55 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-13 07:55:18 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Eclipse Project 433606 None None None Never

Description Carlos O'Donell 2014-11-04 18:06:53 UTC
Steps to reproducer:

(a) On F20 install eclipse.

[carlos@koi ~]$ uname -a
Linux koi 3.16.2-201.fc20.x86_64 #1 SMP Mon Sep 15 19:57:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[carlos@koi ~]$ rpm -qa | grep eclipse
icu4j-eclipse-50.1.1-2.fc20.noarch
eclipse-pde-4.3.2-3.fc20.x86_64
eclipse-dtp-1.11.2-1.fc20.noarch
eclipse-jbosstools-parent-4.1.1-2.fc20.noarch
eclipse-jbosstools-4.1.1-2.fc20.noarch
eclipse-wtp-webservices-3.5.1-1.fc20.noarch
eclipse-ecf-core-3.8.0-1.fc20.noarch
eclipse-emf-2.9.2-1.fc20.noarch
eclipse-egit-3.3.2-1.fc20.noarch
eclipse-jbosstools-foundation-4.1.1-2.fc20.noarch
eclipse-emf-xsd-2.9.2-1.fc20.noarch
eclipse-jbosstools-ws-4.1.1-2.fc20.noarch
eclipse-jbosstools-jst-4.1.1-2.fc20.noarch
eclipse-wtp-servertools-3.5.1-1.fc20.noarch
eclipse-wtp-jpa-3.5.1-1.fc20.noarch
eclipse-wtp-jeetools-3.5.1-1.fc20.noarch
eclipse-jbosstools-jmx-4.1.1-2.fc20.noarch
eclipse-jbosstools-archives-4.1.1-2.fc20.noarch
eclipse-emf-core-2.9.2-1.fc20.noarch
eclipse-jbosstools-usage-4.1.1-2.fc20.noarch
eclipse-wtp-jsf-sdk-3.5.1-1.fc20.noarch
eclipse-cdt-8.3.0-1.fc20.x86_64
eclipse-mylyn-3.10.0-2.fc20.noarch
eclipse-equinox-osgi-4.3.2-3.fc20.x86_64
eclipse-wtp-sourceediting-3.5.1-2.fc20.noarch
eclipse-wtp-jpa-sdk-3.5.1-1.fc20.noarch
eclipse-jbosstools-freemarker-4.1.1-2.fc20.noarch
eclipse-platform-4.3.2-3.fc20.x86_64
eclipse-p2-discovery-4.3.1-1.fc20.noarch
eclipse-rse-3.5-3.fc20.noarch
eclipse-emf-sdk-2.9.2-1.fc20.noarch
eclipse-jbosstools-as-4.1.1-2.fc20.noarch
eclipse-gef-3.9.1-0.2.gitb9f2e9.fc20.noarch
eclipse-jbosstools-cdi-4.1.1-2.fc20.noarch
eclipse-wtp-common-3.5.1-1.fc20.noarch
eclipse-jbosstools-common-4.1.1-2.fc20.noarch
eclipse-wtp-jsf-3.5.1-1.fc20.noarch
eclipse-jbosstools-runtime-4.1.1-2.fc20.noarch
eclipse-jbosstools-stacks-4.1.1-2.fc20.noarch
eclipse-swt-4.3.2-3.fc20.x86_64
eclipse-m2e-core-1.4.0-12.fc20.noarch
eclipse-jdt-4.3.2-3.fc20.x86_64
eclipse-jgit-3.3.2-1.fc20.noarch
eclipse-jbosstools-openshift-4.1.1-2.fc20.noarch

(b) Start eclipse and select a new workspace that doesn't exist.
~~~
[carlos@koi ~]$ eclipse -debug -consoleLog
Start VM: /usr/bin/java
-Xms128m
-Xmx512m
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
-Dhelp.lucene.tokenizer=standard
-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith
-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init>
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding
-XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile
-XX:CompileCommand=exclude,org/eclipse/tycho/core/osgitools/EquinoxResolver,newState
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins
-Declipse.p2.skipMovedInstallDetection=true
-XX:MaxPermSize=256m
-jar /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.3.0.v20140324-2308.jar
-os linux
-ws gtk
-arch x86_64
-showsplash /usr/lib64/eclipse//plugins/org.eclipse.platform_4.3.2.v20140324-2304/splash.bmp
-launcher /usr/lib64/eclipse/eclipse
-name Eclipse
--launcher.library /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20140324-2308/eclipse_1508.so
-startup /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.3.0.v20140324-2308.jar
--launcher.appendVmargs
-exitdata 2afb8015
-preventMasterEclipseLaunch
-debug
-consoleLog
-vm /usr/bin/java
-vmargs
-Xms128m
-Xmx512m
-Dorg.eclipse.swt.browser.UseWebKitGTK=true
-Dhelp.lucene.tokenizer=standard
-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith
-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init>
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding
-XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile
-XX:CompileCommand=exclude,org/eclipse/tycho/core/osgitools/EquinoxResolver,newState
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins
-Declipse.p2.skipMovedInstallDetection=true
-XX:MaxPermSize=256m
-jar /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.3.0.v20140324-2308.jar 
CompilerOracle: exclude org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith
CompilerOracle: exclude org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init>
CompilerOracle: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate
CompilerOracle: exclude org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding
CompilerOracle: exclude org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile
CompilerOracle: exclude org/eclipse/tycho/core/osgitools/EquinoxResolver.newState
Install location:
    file:/usr/lib64/eclipse/
Configuration file:
    file:/usr/lib64/eclipse/configuration/config.ini loaded
Configuration location:
    file:/home/carlos/.eclipse/org.eclipse.platform_793567567_linux_gtk_x86_64/configuration/
Configuration file:
    file:/home/carlos/.eclipse/org.eclipse.platform_793567567_linux_gtk_x86_64/configuration/config.ini loaded
Loading timestamp file from:
	 file:/home/carlos/.eclipse/org.eclipse.platform_793567567_linux_gtk_x86_64/configuration/   .baseConfigIniTimestamp
Timestamps found: 
	 config.ini in the base: 1395704467000
	 remembered 1395704467000
Shared configuration location:
    file:/usr/lib64/eclipse/configuration/
Framework located:
    file:/usr/lib64/eclipse/plugins/org.eclipse.osgi_3.9.1.v20140324-2308.jar
Framework classpath:
    file:/usr/lib64/eclipse/plugins/org.eclipse.osgi_3.9.1.v20140324-2308.jar
Splash location:
    /usr/lib64/eclipse//plugins/org.eclipse.platform_4.3.2.v20140324-2304/splash.bmp
Debug options:
    file:/home/carlos/.options not found
Time to load bundles: 5
Starting application: 1932
Application Started: 6888
No bp log location saved, using default.
[000:000] Cpu: 6.58.9, x4, 3600Mhz, 15749MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:000] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.58.9, x4, 3600Mhz, 15749MB
[000:000] Computer model: Not available
[000:022] No bp log location saved, using default.
[000:023] Cpu: 6.58.9, x4, 3600Mhz, 15749MB
[000:024] Computer model: Not available
[000:024] Browser XEmbed support present: 1
[000:024] Browser toolkit is Gtk2.
[000:024] Using Gtk2 toolkit
[carlos@koi ~]$ 
~~~

Expected behaviour:
- Eclipse starts.

Observed behviour:
- Eclipse exits with no error.

Traditionally `-consoleLog` has always been sufficient to show me what was broken, but I see nothing after `Using Gtk2 toolkit`.

Workaround:
- Restart eclipse again with the same workspace and it works.

Comment 1 Carlos O'Donell 2014-11-04 19:02:04 UTC
This is caused by the proprietary Blue Jeans plugins.

IMO F20, and any distribution we still support should ship a workaround.

For example, blacklist the plugins:

cat >> blacklist.c <<EOF
/* dlopen interposer to blacklist plugins.  */
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dlfcn.h>
/* Set of plugins to blacklist.  */
char *blacklist[] = {
"/usr/lib64/mozilla/plugins/nprbjninstallplugin_2.7.236.8.so",
"/usr/lib64/mozilla/plugins/nprbjnplugin_2.7.236.8.so",
"/usr/lib64/mozilla/plugins/npbjninstallplugin_2.6.255.8.so",
"/usr/lib64/mozilla/plugins/npbjnplugin_2.6.255.8.so",
NULL,
};
/* Blacklist plugin name string lengths (precomputed).  */
int bllen[] = { 59, 52, 58, 51, 0, };
/* Interposed dlopen that does blacklisting: */
void *
dlopen (const char *filename, int flag)
{
  int i = 0;
  /* Make this MT-safe by doing it for each caller.  */
  void *(*real_dlopen)(const char *, int); 
  dlerror ();
  *(void **) (&real_dlopen) = dlsym (RTLD_NEXT, "dlopen");
  if (real_dlopen == NULL)
    {
      fprintf (stderr, "%s\n", dlerror ());
      exit (1);
    }
  /* Shortcut if the filename is NULL open the local image.  */
  if (filename == NULL)
    return (*real_dlopen) (filename, flag);
  /* Scan the blacklist...  */
  do
    {
      if (strncmp (filename, blacklist[i], bllen[i]) == 0)
	return NULL;
      i++;
    }
  while (blacklist[i] != NULL);
  /* Do the normal lookup.  */
  return (*real_dlopen) (filename, flag);
}
EOF
gcc -Wall -pedantic -g3 -O3 -Wl,-soname=libblacklist64.so -shared -fPIC -o libblacklist64.so blacklist.c
gcc -Wall -pedantic -m32 -g3 -O3 -Wl,-soname=libblacklist32.so -shared -fPIC -o libblacklist32.so blacklist.c

LD_PRELOAD=./libblacklist64.so:./libblacklist32.so eclipse -debug -consoleLog

And everything starts up as expected.

Please add the workaround to F20 :-)

Comment 2 Carlos O'Donell 2014-11-04 19:38:21 UTC
If the maintainers in Fedora don't wish to slow down dlopen (though IMO the slowdown is negligable compared to the symbol lookup phase), at the very least eclipse should be wrapped to detect the plugins, issue a sensible error, and exit. Exiting with an exit code of 0 during a failure is also wrong.

Comment 3 Alexander Kurtakov 2014-11-05 08:02:00 UTC
Cleanest solution for me is to make eclipse-platform Conflict with bluejeans rpm. There are the reasons why I don't like the approach you propose:
* if we blacklist we should blacklist /usr/lib64/mozilla/plugins/np*bjn*.so as rebuilding eclipse to add new version/name is a no-go due to secondary architectures which have big problems building Java stuff and often miss some rebuilds resulting in bootstraps there.
* speed is also a problem as eclipse runs itself while building itself and we used to exceed the 24 limit for builds on arm(which is primary arch), currently at 14h while only 40mins on x86. Many changes that has no effect on x86 happen to have enormous effect on arm so I would rather not slowdown for BlueJeans.

So conflicts is the best solution in my eyes.
With all that said we have a backport of F21 Eclipse for F20 (http://copr.fedoraproject.org/coprs/mbooth/eclipse-luna/) which can be installed and run using GTK3 (export SWT_GTK3=1) and WebKit2 (export SWT_WEBKIT2=1) which will make eclipse not crash as webkit will run plugins out of process so they will not bring down everything. Spending time on improving the real fix (just described) while not allowing both being installed is best long term solution from my POV. 
And please don't forget to push BlueJeans to fix their stuff https://bugs.eclipse.org/bugs/show_bug.cgi?id=433606 :).

Comment 4 Carlos O'Donell 2014-11-05 14:45:32 UTC
(In reply to Alexander Kurtakov from comment #3)
> Cleanest solution for me is to make eclipse-platform Conflict with bluejeans
> rpm. 

That's a mean solution for users that prevents them from using two pieces of technology that can be made to work together.

> There are the reasons why I don't like the approach you propose:
> * if we blacklist we should blacklist /usr/lib64/mozilla/plugins/np*bjn*.so
> as rebuilding eclipse to add new version/name is a no-go due to secondary
> architectures which have big problems building Java stuff and often miss
> some rebuilds resulting in bootstraps there.

Easily done.

Shorten the blacklist string to include only the name without version number, adjust bllen to match the length, and strncmp only compares *up to* that number.

e.g.
char *blacklist[] = {
"/usr/lib64/mozilla/plugins/nprbjninstallplugin",
"/usr/lib64/mozilla/plugins/nprbjnplugin",
"/usr/lib64/mozilla/plugins/npbjninstallplugin",
"/usr/lib64/mozilla/plugins/npbjnplugin",
NULL,
};
/* Blacklist plugin name string lengths (precomputed).  */
int bllen[] = { 46, 39, 45, 38, 0, };

Which is effectively:
/usr/lib64/mozilla/plugins/nprbjninstallplugin*
/usr/lib64/mozilla/plugins/nprbjnplugin*
/usr/lib64/mozilla/plugins/npbjninstallplugin*
/usr/lib64/mozilla/plugins/npbjnplugin*

On i686 I don't know what you have?
/usr/lib/mozilla/plugins/nprbjninstallplugin*
/usr/lib/mozilla/plugins/nprbjnplugin*
/usr/lib/mozilla/plugins/npbjninstallplugin*
/usr/lib/mozilla/plugins/npbjnplugin*
So you need 4 more entries to the blacklist table and bllen table.

It's not quite what you wanted, but still functions well. I doubt bluejeans is going to change the names of their plugins any time soon, and if it does you can push an update for the blacklist blocker.

> * speed is also a problem as eclipse runs itself while building itself and
> we used to exceed the 24 limit for builds on arm(which is primary arch),
> currently at 14h while only 40mins on x86. Many changes that has no effect
> on x86 happen to have enormous effect on arm so I would rather not slowdown
> for BlueJeans.

Try it. Tell me if you can notice a performance difference. The dlopen call is the small part of the whole process, the future symbol resolution passes are *much* *much* more expensive than this interposer.

> So conflicts is the best solution in my eyes.

I disagree, it's the easiest, but not the best.

You need also only use this solution for Fedora releases that have the problem. If it's fixed in F21 then it need not have this stopgap solution.

> With all that said we have a backport of F21 Eclipse for F20
> (http://copr.fedoraproject.org/coprs/mbooth/eclipse-luna/) which can be
> installed and run using GTK3 (export SWT_GTK3=1) and WebKit2 (export
> SWT_WEBKIT2=1) which will make eclipse not crash as webkit will run plugins
> out of process so they will not bring down everything. Spending time on
> improving the real fix (just described) while not allowing both being
> installed is best long term solution from my POV.

That's a lot of work for the average user that just wants Eclipse working and happens to have BJ installed.

Does F21 Eclipse work out of the box with BJ installed?

> And please don't forget to push BlueJeans to fix their stuff
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=433606 :).

I sent email to BlueJeans.

Comment 5 Alexander Kurtakov 2014-11-13 08:22:53 UTC
Mat, what do you think - Should we conflict with bluejeans packages or complicate even more the build ?

Comment 6 Mat Booth 2014-12-12 17:31:58 UTC
I will document this problem on the Fedora 21 "Common Bugs" page and probably will find time to implement Carlos' suggestion in an update. I guess I don't mind complicating the build for Fedoras < 22 since F22 is now where the bulk of development will happen, and we are using GTK3 by default in F22+

Comment 8 Carlos O'Donell 2015-01-19 16:16:22 UTC
Another workaround is to disable xulrunner and use an external browser:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=433606#c14

Comment 9 Alexander Kurtakov 2015-02-25 09:23:59 UTC
*** Bug 1115174 has been marked as a duplicate of this bug. ***

Comment 10 Alexander Kurtakov 2015-05-13 07:55:18 UTC
Latest bluejeans plugin (version 2.90.616.8) finally fixes the problem. Marking as fixed, please reopen if it still happens for you after updating it.


Note You need to log in before you can comment on or make changes to this bug.