[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-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
16 years, 3 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
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