Bug 1160411

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 :-)

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.

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 :).

(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.

Mat, what do you think - Should we conflict with bluejeans packages or complicate even more the build ?

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+

Another workaround is to disable xulrunner and use an external browser:

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

*** Bug 1115174 has been marked as a duplicate of this bug. ***

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.