rgrunber

Tag: systemtap

F20 + Eclipse + Google Talk Plugin = A Bad Time

A little while ago, a colleague discovered a strange issue that seems to make Eclipse crash fairly predictably. With the release of Fedora 20, I’ve seen others discover this bug. It’s known upstream and the obvious approaches (Comments 18, and 21) don’t seem to work as expected. It seems that disabling plugin support isn’t enough because the API itself is likely calling dlopen to load the plugins and maybe inserting them into some registry. This is sufficient to cause the crash. I was thinking about maybe disabling the dlopen call altogether on the relevant plugins as a temporary workaround / proof of concept, and it seems like a promising approach.

probe process("/lib64/libdl.so").function("__dlopen") {
 f = user_string($file)
 if ( cmdline_str() =~ "org.eclipse" && f =~ "google" ) {
 printf ("disabling dlopen for %s (%d) on %s \n", execname(), pid(), f)
 $file=0
 }
}
stap -v -g --suppress-handler-errors dlopen.stp

f20-eclipse-google-talkplugin

To be honest, I haven’t tried running this for any significant period of time so this is somewhere in between just a toy example and a workaround for people who really need both Eclipse and Google Talk Plugin on their systems. This isn’t ideal, but probably an improvement from ‘yum remove -y google-talkplugin’, and I couldn’t help trying a random hack to “fix” it.

It looks like SystemTap is a really awesome, versatile tool, but maybe I’m pushing square pegs through a round hole as well. I guess I should take on world peace for my next post .. using SystemTap (I’m sure there’s a tapset for that).

Support for Java Probing in SystemTap

The Java support for SystemTap looks promising, and I can think of a few different usages for this.

I ran into an issue where Eclipse was throwing some ClassNotFoundExceptions during its shutdown in F20. Granted, it was possible to insert a breakpoint at the location mentioned and just resume at each point, or even perform a hot-code insertion to get the classes that weren’t being found, but these approaches can be a little tricky. In both cases you’d pretty much need to remotely debug one running Eclipse instance from another assuming the instance in question was severely broken.

Using the SystemTap Java probes seemed like a relatively simple solution. There are of course some limitations and a bit of setup necessary but with the small script below it was easy to narrow down the issue.

probe java("/usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.3.0.v20131104-1241.jar").class("java.net.URLClassLoader").method("findClass(String):366") {
printf("ClassNotFoundException : %s\n", user_string($arg1))
}

It was still necessary to remotely debug since there was no way of getting a stacktrace, but I’ve been assured by Lukas, one of the developers, that such a feature should be possible. You can also see his original post on the topic of Java probing.

Minor Amendment : Replace ‘assured’ with ‘given a wink and a maaayyybe’ . If it’s technically possible, I’m sure it’ll be added.