[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
14 years, 9 months
[JBoss JIRA] Created: (JASSIST-98) javassist appears to be iinstalling invalid local variable tables
by Andrew Dinn (JIRA)
javassist appears to be iinstalling invalid local variable tables
-----------------------------------------------------------------
Key: JASSIST-98
URL: https://jira.jboss.org/jira/browse/JASSIST-98
Project: Javassist
Issue Type: Bug
Reporter: Andrew Dinn
Assignee: Shigeru Chiba
The problem manifested when using the Byteman runtime agent to transform a class which has already been transformed offline using AOP. It appears that the code generated by AOP using javassist.has an invalid entry in the local variable table. When it is retransfromed (by vanilla ObjectWeb ASM code) the error is compounded resulting in a load exception on the class.
The code which causes the problem is in the JBoss Messaging code in jboss-messaging.jar version 1.4.1.GA (or so the AS component matrix says). The method name is
org$jboss$jms$client$delegate$ClientClusteredConnectionFactoryDelegate$getClientAOPStack$aop()
The relevant section of the decompiled code is as follows:
public synchronized byte[] org$jboss$jms$client$delegate$ClientClusteredConnectionFactoryDelegate$getClientAOPStack$aop() throws javax.jms.JMSException;
Code:
Stack=3, Locals=3, Args_size=1
0: getstatic #397; //Field org/jboss/jms/client/delegate/ClientClusteredConnectionFactoryDelegate.log:Lorg/jboss/logging/Logger;
3: new #71; //class java/lang/StringBuilder
. . .
77: invokevirtual #434; //Method org/jboss/logging/Logger.trace:(Ljava/lang/Object;)V
80: aload_2
81: invokeinterface #438, 1; //InterfaceMethod org/jboss/jms/delegate/ConnectionFactoryDelegate.getClientAOPStack:()[B
86: areturn
87: astore_2
88: getstatic #440; //Field org/jboss/jms/client/delegate/ClientClusteredConnectionFactoryDelegate.log:Lorg/jboss/logging/Logger;
. . .
LocalVariableTable:
Start Length Slot Name Signature
52 32 2 aopStackProvider Lorg/jboss/jms/delegate/ConnectionFactoryDelegate;
85 31 2 e Lorg/jboss/jms/exception/MessagingNetworkFailureException;
36 86 1 server I
0 132 0 this Lorg/jboss/jms/client/delegate/ClientClusteredConnectionFactoryDelegate;
Exceptions:
throws javax.jms.JMSException Synthetic: true
The entry for aopStackProvider has a valid start position but the length value places its end at position 84 which is not an instruction boundary. It probably ought to add up to 87 i.e.the instruction after the return since the variable will probably be in scope up to and including the return.
The entry for e has an invalid start and end position. First, it is not an instruction boundary. Second, it tarverses a return instruction.
The compounded error manifests as follows during subsequent transformation. When the ASM code transforms this class the reader generates labels for the start and end positions and later visits them as it traverses the input bytecode. However, it only visits labels whose index matches aninstruction boundary. So the invalid entries end up with offset 0. When the transformed code is output the table looks like:
LocalVariableTable:
Start Length Slot Name Signature
52 -52 2 aopStackProvider Lorg/jboss/jms/delegate/ConnectionFactoryDelegate;
0 0 2 e Lorg/jboss/jms/exception/MessagingNetworkFailureException;
36 -36 1 server I
0 0 0 this Lorg/jboss/jms/client/delegate/ClientClusteredConnectionFactoryDelegate;
The length for aopStackProvider is calculated as end - start i.e. 0 - 52. This negative length is detected by the JVM and the load for the class throws an exception.
--
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
14 years, 9 months
[JBoss JIRA] Created: (JASSIST-99) Javassist causes java.lang.ClassFormatError: Invalid length 561 in LocalVariableTable in class file
by Martin Burger (JIRA)
Javassist causes java.lang.ClassFormatError: Invalid length 561 in LocalVariableTable in class file
---------------------------------------------------------------------------------------------------
Key: JASSIST-99
URL: https://jira.jboss.org/jira/browse/JASSIST-99
Project: Javassist
Issue Type: Bug
Affects Versions: 3.11.0.GA
Reporter: Martin Burger
Assignee: Shigeru Chiba
I am instrumenting field accesses in Java classes. Unfortunately, this fails in some cases, the manipulated byte code causes a java.lang.ClassFormatError:
Exception in thread "main" java.lang.ClassFormatError: Invalid length 561 in LocalVariableTable in class file de/unisb/cs/st/deltadebugging/jinsi/test/integration/events/outgoing/fieldaccesses/SuperClassOfObserved
at java.lang.ClassLoader.defineClass1(Native Method)
...
This issue occurred in 3.11.0.GA and is not fixed in r505. Maybe this is related to JASSIST-98. In 3.10.0.GA, this issue does not exist, the affected class can be loaded without any error.
I tried to analyze the corrupt class file with javassist.tools.framedump, but the analysis fails:
Exception in thread "main" java.lang.RuntimeException: javassist.bytecode.BadBytecode: Could not find class in descriptor [pos = 8]: de.unisb.cs.st.deltadebugging.jinsi.test.integration.events.outgoing.fieldaccesses.Unobserved
at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:89)
...
I decompiled both classes (the working one and the corrupt one) using JAD, the output differs slightly:
43c43
< /* 16*/ JVM INSTR new #96 <Class Long>;
---
> /* 16*/ JVM INSTR new #102 <Class Long>;
59c59
< /* 16*/ JVM INSTR new #96 <Class Long>;
---
> /* 16*/ JVM INSTR new #102 <Class Long>;
Here is the corrupt decompiled code of line 16. Compared to the working class, lines 43 and 59 seem to be switched:
28 /* 16*/ obj = this;
29 /* 16*/ Unobserved unobserved1 = null;
30 /* 16*/ unobserved1 = ((SuperClassOfObserved) (obj)).unobserved;
31 /* 16*/ EventRecorderFactory.getInstance().recordOutgoingFieldRead(this, JinsiClassUtils.getClassOfObject(this), obj, Desc.getClazz("de.unisb.cs.st.deltadebugging.jinsi.test.integration.events.outgoing.fieldaccesses.SuperClassOfObserved"), "unobserved", unobserved1, Desc.getType("Lde/unisb/cs/st/deltadebugging/jinsi/test/integration/events/outgoing/fieldaccesses/Unobserved;"), "SuperClassOfObserved.java", 16, Context.METHOD);
32 /* 16*/ EventRecorderFactory.getInstance().recordIncomingFieldRead(this, JinsiClassUtils.getClassOfObject(this), obj, Desc.getClazz("de.unisb.cs.st.deltadebugging.jinsi.test.integration.events.outgoing.fieldaccesses.SuperClassOfObserved"), "unobserved", unobserved1, Desc.getType("Lde/unisb/cs/st/deltadebugging/jinsi/test/integration/events/outgoing/fieldaccesses/Unobserved;"), "SuperClassOfObserved.java", 16, Context.METHOD);
33 /* 16*/ obj = unobserved1;
34 /* 16*/ l = 0L;
35 /* 16*/ l = ((Unobserved) (obj)).fieldLong;
36 /* 16*/ EventRecorderFactory.getInstance();
37 /* 16*/ this;
38 /* 16*/ JinsiClassUtils.getClassOfObject(this);
39 /* 16*/ obj;
40 /* 16*/ Desc.getClazz("de.unisb.cs.st.deltadebugging.jinsi.test.integration.events.outgoing.fieldaccesses.Unobserved");
41 /* 16*/ "fieldLong";
42 /* 16*/ l;
43 /* 16*/ JVM INSTR new #102 <Class Long>;
44 /* 16*/ JVM INSTR dup ;
45 /* 16*/ Long();
46 /* 16*/ Desc.getType("J");
47 /* 16*/ "SuperClassOfObserved.java";
48 /* 16*/ 16;
49 /* 16*/ Context.METHOD;
50 /* 16*/ recordOutgoingFieldRead();
51 /* 16*/ JVM INSTR pop ;
52 /* 16*/ EventRecorderFactory.getInstance();
53 /* 16*/ this;
54 /* 16*/ JinsiClassUtils.getClassOfObject(this);
55 /* 16*/ obj;
56 /* 16*/ Desc.getClazz("de.unisb.cs.st.deltadebugging.jinsi.test.integration.events.outgoing.fieldaccesses.Unobserved");
57 /* 16*/ "fieldLong";
58 /* 16*/ l;
59 /* 16*/ JVM INSTR new #102 <Class Long>;
60 /* 16*/ JVM INSTR dup ;
61 /* 16*/ Long();
62 /* 16*/ Desc.getType("J");
63 /* 16*/ "SuperClassOfObserved.java";
64 /* 16*/ 16;
65 /* 16*/ Context.METHOD;
66 /* 16*/ recordIncomingFieldRead();
67 /* 16*/ JVM INSTR pop ;
68 /* 16*/ long fieldLong = l;
However, I don't know if this is related to the defect.
--
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
14 years, 9 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
14 years, 9 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
14 years, 9 months