felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Felix and JamVM deadlock in ClassLoader
Date Tue, 12 Nov 2013 09:51:20 GMT
Well, my guess would be that you are running into some form of a circular
class load issue. The point is that the class loader in java is
synchronized which my lead to deadlocks if you have a cycle in your class
loaders. This is a long standing issue with frameworks like OSGi which
allow for cycles in the dependencies.

I don't know enough about your app to say for sure nor to help you with
this but look at the dependencies of your bundles and see whether they
create a cycle (i.e., Bundle A depends via some import on Bundle B which
depends via some import on Bundle C which depends via some import on Bundle
A or something similar). In your case, it might be even more complicated as
the retrotranslator seems to do some class loading magic by itself which
might be responsible for the issue - how do you make the
net.sf.retrotranslator.*
packages available to the bundles?

regards,

Karl


On Fri, Nov 8, 2013 at 10:44 PM, Daniel McGreal <daniel@redbite.com> wrote:

> Hello Felix developer community,
>
> I am having an interesting (and critical) problem running my application
> with Felix in an embedded environment where an alternate JVM, JamVM is
> necessary.
>
> The deadlock is non-deterministic with the deadlocked stack traces
> blocking at odd places (though they might not seem odd to people used to
> messing with class loading - but a block on new XXX() to me is quite the
> novelty). An example of the relevant parts of the thread stack is in
> FelixJamVMDeadlockStackTrace.txt, attached. It shows a lock between:
>
>
>    -
>    - java.lang.ClassLoader.findLoadedClass(ClassLoader.java:580) looks
>    like:
>
>      protected final synchronized Class<?> findLoadedClass(String name)
>     {
>        checkInitialized();
>        return VMClassLoader.findLoadedClass(this, name);
>     }
>
>    where line 580 is checkInitialized() which throws an exception if
>    isInitialized is false.
>
>    - net.sf.retrotranslator.runtime.asm.ClassReader.readConst(ClassReader.java:1591)
>    looks like:
>
>        public Object readConst(final int item, final char[] buf) {
>            int index = items[item];
>            switch (b[index - 1]) {
>                case ClassWriter.INT:
>                    return new Integer(readInt(index));
>                case ClassWriter.FLOAT:
>                    return new Float(Float.intBitsToFloat(readInt(index)));
>                case ClassWriter.LONG:
>                    return new Long(readLong(index));
>                case ClassWriter.DOUBLE:
>                    return newDouble(Double.longBitsToDouble(readLong(index)));
>                case ClassWriter.CLASS:
>                    String s = readUTF8(index, buf);
>                    return Type.getType(s.charAt(0) == '[' ? s : "L" + s +
>    ";");
>                // case ClassWriter.STR:
>                default:
>                    return readUTF8(index, buf);
>            }
>        }
>    where line 1591 is return new Integer(readInt(index));
>
>    -
>    -
>    - org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2038)
>    is a big method, where line 2038 looks inconspicuously like:
>
>    if (!hooks.isEmpty())
>
>
> Gogo and Retrotranslator are red herrings, without them in the application
> the deadlock just happens somewhere else.
>
> I don't even vaguely understand how, but neither Eclipse nor Knopflerfish
> suffer from this problem. I would, however, much rather use Felix.
>
> Please let me know if there's any further information I can provide.
>
> Best, Dan.
>
>
>
>
>
>


-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message