LinkageError problem

Created March 17, 2017 09:05

Hi everyone,

A couple of my users have reported a performance issue when working on a particular open source project. I've never been able to reproduce it. However I'm working with one of the users now who has found at least one problem - at some point when working on this project, IntelliJ starts spewing massive amounts of the following exception into the logs:

2017-03-17 09:39:56,471 [2140938] ERROR - llij.ide.plugins.PluginManager - com/intellij/openapi/diagnostic/IdeaLoggingEvent
java.lang.LinkageError: com/intellij/openapi/diagnostic/IdeaLoggingEvent
 at com.intellij.diagnostic.DialogAppender.appendToLoggers(DialogAppender.java:79)
 at com.intellij.diagnostic.DialogAppender.lambda$append$0(DialogAppender.java:63)
 at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
 at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
 at java.awt.EventQueue.access$500(EventQueue.java:97)
 at java.awt.EventQueue$3.run(EventQueue.java:709)
 at java.awt.EventQueue$3.run(EventQueue.java:703)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
 at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
 at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:843)
 at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:679)
 at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:391)
 at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
 at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
 at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Unfortunately it happens so quickly that he can't kill IntelliJ before it rolls over the log file limit - it basically fills up all the files immediately, so it's hard to tell if there's some exception at the start of this which provokes the problem. But the error looks very strange, it seems to imply that the versions of PluginManager and IdeaLoggingEvent are different? I'm not sure how that could be.

If I should file a YouTrack issue about this instead, please let me know.

4 comments

Peter Gromov

Created March 17, 2017 09:38

Official comment

So do I understand correctly that SOE happens during classloading? That's quite unfortunate, all kinds of internal data structures can go wrong in such situations. I believe the only way out is to fix the SOE. Hopefully http://openjdk.java.net/jeps/270 will fix that some day.

Colin Fleming

Created March 17, 2017 09:17

Actually, he managed to get the first exception by tailing into a file, this time it's related to my plugin:

2017-03-17 10:06:06,544 [  40839]  ERROR - aemon.impl.PassExecutorService - loader constraint violation: loader (instance of com/intellij/util/lang/UrlClassLoader) previously initiated loading for a different type with name "com/intellij/openapi/diagnostic/IdeaLoggingEvent" 
java.lang.LinkageError: loader constraint violation: loader (instance of com/intellij/util/lang/UrlClassLoader) previously initiated loading for a different type with name "com/intellij/openapi/diagnostic/IdeaLoggingEvent"
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
	at com.intellij.util.lang.UrlClassLoader._defineClass(UrlClassLoader.java:276)
	at com.intellij.util.lang.UrlClassLoader.defineClass(UrlClassLoader.java:272)
	at com.intellij.util.lang.UrlClassLoader.findClass(UrlClassLoader.java:226)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
	at com.intellij.util.lang.UrlClassLoader._defineClass(UrlClassLoader.java:276)
	at com.intellij.util.lang.UrlClassLoader.defineClass(UrlClassLoader.java:272)
	at com.intellij.util.lang.UrlClassLoader.findClass(UrlClassLoader.java:226)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at com.intellij.diagnostic.LogMessageEx.createEvent(LogMessageEx.java:103)
	at com.intellij.diagnostic.LogMessageEx.createEvent(LogMessageEx.java:75)
	at cursive.resolve.symbol$resolve_symbol.invoke(symbol.clj:109)
	at clojure.lang.Var.invoke(Var.java:383)
        <snip huge stack overflow trace>

What's happening here is that there's a stack overflow produced during the symbol resolution. I added some code to create a logging event, so that users could report the problem with the problematic code snippet attached. However for some reason that causes this issue, although I have no idea why.

Colin Fleming

Created March 17, 2017 09:44

No, the SOE happens during symbol resolution. I wrap my resolve in a try/catch SOE, and I guess the classloading happens in the catch block when I try to create the logging event.

Peter Gromov

Created March 17, 2017 10:45

That's still a (secondary) SOE that happens to happen in classloader code.

Please sign in to leave a comment.