[JBoss JIRA] Created: (JASSIST-80) Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | invalid instruction
by Martin Burger (JIRA)
Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | invalid instruction
-------------------------------------------------------------------------------------------------------------------------------
Key: JASSIST-80
URL: https://jira.jboss.org/jira/browse/JASSIST-80
Project: Javassist
Issue Type: Bug
Affects Versions: 3.10.0.GA
Environment: $ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
Reporter: Martin Burger
Assignee: Shigeru Chiba
Note: Most likely this issue is related to JASSIST-79.
I instrument method calls in a class called org.mozilla.javascript.TokenStream.
If I run (or, load) this class, a java.lang.VerifyError will be thrown:
Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/TokenStream, method: getToken$JINSI_4etOXffNDXVw signature: ()I) Illegal target of jump or branch
It seems Javassist introduces a defective goto statement at position 33217 in method getToken$JINSI_4etOXffNDXVw:
33217 goto 465
The corresponding Java code (excerpt):
case '-':
if (matchChar('=')) {
this.op = SUB;
c = ASSIGN;
} else if (matchChar('-')) {
if (0 == (flags & TSF_DIRTYLINE)) {
// treat HTML end-comment after possible whitespace
// after line start as comment-utill-eol
if (matchChar('>')) {
skipLine();
continue retry;
}
}
c = DEC;
} else {
c = SUB;
}
flags |= TSF_DIRTYLINE;
return c;
I think the continue statement is related to this defect.
JAD fails to decompile the instrumented class:
ERROR: invalid instruction at 33217 in the method getToken$JINSI_4etOXffNDXVw. The method will be decompiled incorrectly.
Javassist's framedump fails, too:
Exception in thread "main" java.lang.RuntimeException: javassist.bytecode.BadBytecode: Stack is empty[pos = 465]
at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:89)
at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:60)
at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:51)
at javassist.tools.framedump.main(framedump.java:45)
Caused by: javassist.bytecode.BadBytecode: Stack is empty[pos = 465]
at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:179)
at javassist.bytecode.analysis.Analyzer.analyze(Analyzer.java:143)
at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:87)
... 3 more
Caused by: java.lang.IndexOutOfBoundsException: Stack is empty
at javassist.bytecode.analysis.Frame.pop(Frame.java:130)
at javassist.bytecode.analysis.Executor.simplePop(Executor.java:970)
at javassist.bytecode.analysis.Executor.evalStore(Executor.java:869)
at javassist.bytecode.analysis.Executor.execute(Executor.java:188)
at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:177)
... 5 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JASSIST-86) Make concurrent calls to getRefClasses() safe.
by Shigeru Chiba (JIRA)
Make concurrent calls to getRefClasses() safe.
----------------------------------------------
Key: JASSIST-86
URL: https://jira.jboss.org/jira/browse/JASSIST-86
Project: Javassist
Issue Type: Bug
Affects Versions: 3.10.0.GA
Reporter: Shigeru Chiba
Assignee: Shigeru Chiba
There is a race condition when getRefClasses is called twice concurrently on
the same class - one of the chains in HashMap for collision resolution can become
cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
infinite loop.
On a CtClass ct, the call path leading to the problem is:
ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
not rename anything) -> ct.constPool.renameClass()
One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
then recreates the internal HashMap, i.e. reinserts again all elements into
cp.classes (not a temporary map), so we have concurrent accesses to this map.
In particular, since there can be a collision (as happened for me), the
collision chain could become cyclic.
This was found through remote debugging on a concurrent program using Javassist
(attaching after a series of run-client invocations ended in a crash). It was a
real-world program, not a client written on purpose to show this.
This patch solves the problem well, and was tested in a configuration which caused a
lot of crashes and stopped causing any.
Lots of better fixes to this could be thought, but they're more invasive.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JASSIST-93) VerifyError with addLocalVariable() and insertAfter()
by Joerg Plewe (JIRA)
VerifyError with addLocalVariable() and insertAfter()
-----------------------------------------------------
Key: JASSIST-93
URL: https://jira.jboss.org/jira/browse/JASSIST-93
Project: Javassist
Issue Type: Bug
Environment: javassist 3.11 and 3.5
JDK6
Reporter: Joerg Plewe
Assignee: Shigeru Chiba
Hi all!
This is my first post here and I am a javassist newbie. So hopefully my problem can easily be solved.
>From a real usecase, I condensed the following fragment demonstrating my problem:
Code:
ClassPool cp = ClassPool.getDefault();
CtClass cl = cp.getCtClass("jatest.Test");
CtMethod m = cl.getDeclaredMethod("foo");
m.addLocalVariable("bar", CtClass.longType);
m.insertAfter("bar;", true);
Object o = cl.toClass().newInstance();
The class 'Test' is as simple as it can get:
Code:
public class Test {
public void foo() {}
}
Running the code delivers a VerifyError which I think it shouldn't:
Code:
Exception in thread "main" java.lang.VerifyError: (class: jatest/Test, method: foo signature: ()V) Register pair 1/2 contains
wrong type
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at jatest.Main.main(Main.java:27)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JASSIST-94) Typos in ParameterAnnotationsAttribute javadoc
by Luis Parravicini (JIRA)
Typos in ParameterAnnotationsAttribute javadoc
----------------------------------------------
Key: JASSIST-94
URL: https://jira.jboss.org/jira/browse/JASSIST-94
Project: Javassist
Issue Type: Bug
Reporter: Luis Parravicini
Assignee: Shigeru Chiba
Priority: Trivial
In the documentation of several methods in ParameterAnnotationsAttribute, it says "Visisble" instead of "Visible". I've checked it against 3.9.0.GA. Below is the patch:
diff -ru javassist-3.9.0/src/main/javassist/bytecode/AnnotationsAttribute.java javassist-3.9.0.patched/src/main/javassist/bytecode/AnnotationsAttribute.java
--- javassist-3.9.0/src/main/javassist/bytecode/AnnotationsAttribute.java
2007-06-04 12:10:12.000000000 -0300
+++ javassist-3.9.0.patched/src/main/javassist/bytecode/AnnotationsAttribute.java 2009-09-29 15:52:04.000000000 -0300
@@ -111,7 +111,7 @@
public static final String invisibleTag = "RuntimeInvisibleAnnotations";
/**
- * Constructs a <code>Runtime(In)VisisbleAnnotations_attribute</code>.
+ * Constructs a <code>Runtime(In)VisibleAnnotations_attribute</code>.
*
* @param cp constant pool
* @param attrname attribute name (<code>visibleTag</code> or
@@ -126,7 +126,7 @@
/**
* Constructs an empty
- * <code>Runtime(In)VisisbleAnnotations_attribute</code>.
+ * <code>Runtime(In)VisibleAnnotations_attribute</code>.
* A new annotation can be later added to the created attribute
* by <code>setAnnotations()</code>.
*
diff -ru javassist-3.9.0/src/main/javassist/bytecode/ParameterAnnotationsAttribute.java javassist-3.9.0.patched/src/main/javassist/bytecode/ParameterAnnotationsAttribute.java
--- javassist-3.9.0/src/main/javassist/bytecode/ParameterAnnotationsAttribute.java 2007-06-04 12:10:12.000000000 -0300
+++ javassist-3.9.0.patched/src/main/javassist/bytecode/ParameterAnnotationsAttribute.java 2009-09-29 15:52:20.000000000 -0300
@@ -53,7 +53,7 @@
= "RuntimeInvisibleParameterAnnotations";
/**
* Constructs
- * a <code>Runtime(In)VisisbleParameterAnnotations_attribute</code>.
+ * a <code>Runtime(In)VisibleParameterAnnotations_attribute</code>.
*
* @param cp constant pool
* @param attrname attribute name (<code>visibleTag</code> or
@@ -69,7 +69,7 @@
/**
* Constructs an empty
- * <code>Runtime(In)VisisbleParameterAnnotations_attribute</code>.
+ * <code>Runtime(In)VisibleParameterAnnotations_attribute</code>.
* A new annotation can be later added to the created attribute
* by <code>setAnnotations()</code>.
*
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JASSIST-43) ConstPool.getItem(int) returns unexpected item, causes exceptions in calling methods; e.g. in getFieldrefClassName(...) and getInterfaceMethodrefClassName(...)
by Martin Burger (JIRA)
ConstPool.getItem(int) returns unexpected item, causes exceptions in calling methods; e.g. in getFieldrefClassName(...) and getInterfaceMethodrefClassName(...)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JASSIST-43
URL: http://jira.jboss.com/jira/browse/JASSIST-43
Project: Javassist
Issue Type: Bug
Environment: $ uname -a
Darwin [...] 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
$ java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
Javassist 3.6.0
Reporter: Martin Burger
Assigned To: Shigeru Chiba
I am using subclasses of javassist.expr.ExprEditor to heavily instrument classes. On some large (in terms of amount of code) classes I get various exceptions in ConstPool, for example:
Caused by: java.lang.ClassCastException: javassist.bytecode.ClassInfo
at javassist.bytecode.ConstPool.getFieldrefClassName(ConstPool.java:254)
at javassist.expr.FieldAccess.getClassName(FieldAccess.java:97)
at javassist.expr.FieldAccess.getCtClass(FieldAccess.java:89)
at javassist.expr.FieldAccess.getField(FieldAccess.java:112)
And:
Caused by: java.lang.NullPointerException
at javassist.bytecode.ConstPool.getInterfaceMethodrefClassName(ConstPool.java:413)
at javassist.expr.MethodCall.getClassName(MethodCall.java:91)
at javassist.expr.MethodCall.getCtClass(MethodCall.java:75)
at javassist.expr.MethodCall.getMethod(MethodCall.java:114)
It seems that ConstPool.getItem(int) returns an "unexpected" item, so (1) the cast to FieldrefInfo fails and (2) the returned item is null instead of an instance of InterfaceMethodrefInfo, respectively.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-1260) Performance issue with EjbLinkDemandMetaData
by Guy Coleman (JIRA)
Performance issue with EjbLinkDemandMetaData
--------------------------------------------
Key: EJBTHREE-1260
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1260
Project: EJB 3.0
Issue Type: Bug
Components: core
Affects Versions: AS 5.0.0.Beta4
Reporter: Guy Coleman
We have an application with about 200 EJB3 SLSB and MDBs, 120 EJB2 entity beans and a few web apps.
This takes about 1-2 minutes to start up with JBoss 4.2.2.GA. With 5.0.0.Beta4 this jumps to around 20-30 minutes. Some thread dumps show that it's spending most of its time here:
"main" prio=6 tid=0x044b7430 nid=0x10b4 runnable [0x049cd000..0x049cf9f8]
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at javax.management.JMException.<init>(JMException.java:35)
at javax.management.OperationsException.<init>(OperationsException.java:36)
at javax.management.MalformedObjectNameException.<init>(MalformedObjectNameException.java:35)
at javax.management.ObjectName.construct(ObjectName.java:393)
at javax.management.ObjectName.<init>(ObjectName.java:1304)
at org.jboss.ejb3.dependency.EjbLinkDemandMetaData$EjbLinkDemandDependencyItem.resolve(EjbLinkDemandMetaData.java:134)
at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:140)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:901)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:839)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
at org.jboss.system.ServiceController.doChange(ServiceController.java:659)
at org.jboss.system.ServiceController.create(ServiceController.java:393)
at org.jboss.system.ServiceController.create(ServiceController.java:358)
at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:186)
Patching EjbLinkDemandMetaData to avoid creating ObjectNames for names that are obviously invalid speed this up considerably: the startup time is then about 5 minutes, though It still seems to spend a lot of time looping in that EjbLinkDemandDependencyItem .resolve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months