Hi again, I should give some versions: JamVM 1.5.4 (Classpath 0.98), Latest Felix.
On 8 Nov 2013, at 21:44, Daniel McGreal <[email protected]> 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 new Double(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. > > > <FelixJamVMDeadlockThreadStackTrace.txt> >
