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 11:18:50 GMT
> On the retrotranslator bundles, they are made available by specifying a
> dynamic-import which is added to the manifest during retrotranslation (so
> that our code/libraries can run on).


I would try to change that and either have that bundles each contain their
own copy or to not have them mention it at all in the manifest and just put
them on the class path of the framework and boot delegate.


> Unfortunately, running unretrotranslated does not help.
>

Hm, in that case something else must be going on - however, in your stack
trace it clearly all happens inside the retrotranslate part so you might
have to give me a stack trace of the unretrotranslated one as well.

regards,

Karl

p.s.: feel free to also share your manifests if that is possible

>
> Thanks a lot for your help,
> Dan.
>
> On 12 Nov 2013, at 09:51, Karl Pauls wrote:
>
> > 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
>
>


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