Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

IBM J9 error

See original GitHub issue

SkyWalking gets reports from users in J9 VM. I am not familiar with that. Based on the logs, https://github.com/apache/skywalking/issues/2652#issuecomment-492062199. SkyWalking ProtectiveShieldMatcher prints the logs, such as this

WARN 2019-05-14 10:58:35:839 main ProtectiveShieldMatcher :  Byte-buddy occurs exception when match type. 
java.lang.IllegalStateException: Cannot resolve type description for java.util.Properties
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.pool.TypePool$Resolution$Illegal.resolve(TypePool.java:159)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.pool.TypePool$Default$WithLazyResolution$LazyTypeDescription.delegate(TypePool.java:1407)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.description.type.TypeDescription$AbstractBase$OfSimpleType$WithDelegation.getSuperClass(TypeDescription.java:8024)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.description.type.TypeDescription$Generic$OfNonGenericType.getSuperClass(TypeDescription.java:3619)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.description.type.TypeDefinition$SuperClassIterator.next(TypeDefinition.java:314)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.description.type.TypeDefinition$SuperClassIterator.next(TypeDefinition.java:281)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.HasSuperTypeMatcher.matches(HasSuperTypeMatcher.java:53)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.HasSuperTypeMatcher.matches(HasSuperTypeMatcher.java:31)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Conjunction.matches(ElementMatcher.java:122)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:160)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:160)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:160)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$Junction$Disjunction.matches(ElementMatcher.java:160)

I tried to add some ignore rules for these classes, https://github.com/apache/skywalking/compare/j9-compatible , but look like doesn’t work.

ProtectiveShieldMatcher is following our former discussion, it should just simply print the logs and return false as a fail-safe.

/**
 * In some cases, some frameworks and libraries use some binary codes tech too. From the community feedback, some of
 * them have compatible issues with byte-buddy core, which trigger "Can't resolve type description" exception.
 *
 * So I build this protective shield by a nested matcher. When the origin matcher(s) can't resolve the type, the
 * SkyWalking agent ignores this types.
 *
 * Notice: this ignore mechanism may miss some instrumentations, but at most cases, it's same. If missing happens,
 * please pay attention to the WARNING logs.
 *
 * @author wu-sheng
 */
public class ProtectiveShieldMatcher<T> extends ElementMatcher.Junction.AbstractBase<T> {
    private static final ILog logger = LogManager.getLogger(ProtectiveShieldMatcher.class);

    private final ElementMatcher<? super T> matcher;

    public ProtectiveShieldMatcher(ElementMatcher<? super T> matcher) {
        this.matcher = matcher;
    }

    public boolean matches(T target) {
        try {
            return this.matcher.matches(target);
        } catch (Throwable t) {
            logger.warn(t, "Byte-buddy occurs exception when match type.");
            return false;
        }
    }
}

But this time, it is JVM related classes or eclipse osgi related. does J9VM have some protection mechanism? How should I change the codes?

Issue Analytics

State:
Created 4 years ago
Reactions:2
Comments:45 (11 by maintainers)

Top GitHub Comments

2reactions

wu-shengcommented, May 14, 2019

Also, I noticed the following log

	at org.apache.skywalking.apm.dependencies.net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer.access$1500(AgentBuilder.java:10280)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer$LegacyVmDispatcher.run(AgentBuilder.java:10890)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer$LegacyVmDispatcher.run(AgentBuilder.java:10837)
	at java.security.AccessController.doPrivileged(AccessController.java:386)
	at org.apache.skywalking.apm.dependencies.net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer.transform(AgentBuilder.java:10437)
	at sun.instrument.TransformerManager.transform(TransformerManager.java:201)
	at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:447)
	at java.lang.ClassLoader.defineClassImpl(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:331)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:155)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:800)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:581)
	at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:786)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:764)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:741)
	at org.eclipse.osgi.framework.internal.core.MessageResourceBundle.load(MessageResourceBundle.java:208)
	at org.eclipse.osgi.util.NLS.initializeMessages(NLS.java:88)
	at org.eclipse.osgi.framework.internal.core.Msg.<clinit>(Msg.java:96)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:549)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:484)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:275)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.launch(StartLevelManager.java:245)
	at org.eclipse.osgi.framework.internal.core.SystemBundle.resume(SystemBundle.java:155)
	at org.eclipse.osgi.framework.internal.core.Framework.launch(Framework.java:503)
	at org.eclipse.osgi.framework.internal.core.OSGi.launch(OSGi.java:51)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:289)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:173)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
	at java.lang.reflect.Method.invoke(Method.java:620)
	at org.eclipse.core.launcher.Main.invokeFramework(Main.java:340)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:282)
	at org.eclipse.core.launcher.Main.run(Main.java:981)
	at com.ibm.wsspi.bootstrap.WSPreLauncher.launchEclipse(WSPreLauncher.java:340)
	at com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:110)

Is the osgi class define mechanism causing some conflicts?

0reactions

raphwcommented, Jun 26, 2019

Good to know, thanks for the update!