September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1042) Provide better reporting of ChannelExceptions when debugging

by Richard Achmatowicz (JIRA)

Provide better reporting of ChannelExceptions when debugging ------------------------------------------------------------ Key: JGRP-1042 URL: https://jira.jboss.org/jira/browse/JGRP-1042 Project: JGroups Issue Type: Feature Request Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Priority: Minor I spent a lot of time recently trying to track down some testsuite failures, where tests were failing with: "failed to start protocol stack" org.jgroups.ChannelException at org.jgroups.JChannel.startStack(JChannel.java:1766) at org.jgroups.JChannel.connect(JChannel.java:407) at org.jgroups.JChannel.connect(JChannel.java:382) at org.jgroups.tests.ChannelTest.testBasicOperations(ChannelTest.java:27) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580) at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:49) at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:40) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Turning on DEBUG level logging didn't help. I finally tracked the error down to an UnknownHostException which was getting raised in UDP.createSockets() during a call to InetAddress.getByname(). This checked exception was then passing through the following methods: UDP.createSockets() throws Exception ; UDP.start() throws Exception ; ProtocolStack.startStack() throws Exception ; JChannel.startStack() throws ChannelException ; There are a lot of potential exceptions which can occur when starting a stack, and these are getting masked to a large extent. It makes debugging stack startup problems painful, as the only way to get more information about the problem is to write code to unpack the ChannelException and print out its cause. I'd like to add some simple logging statements to the exception handler in JChannel.startStack() to make debugging the startup of stacks easier. -- 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

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-4591) Create a generic way to createDestinations on MDB Container

by Clebert Suconic (JIRA)

Create a generic way to createDestinations on MDB Container ----------------------------------------------------------- Key: JBAS-4591 URL: http://jira.jboss.com/jira/browse/JBAS-4591 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JB5-Messaging Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.4.0.CR1 We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ. The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods. Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName)) or createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi) -- 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

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2242) Correct the Rete for Clips like LIFO conflict resolution

by Mark Proctor (JIRA)

Correct the Rete for Clips like LIFO conflict resolution -------------------------------------------------------- Key: JBRULES-2242 URL: https://jira.jboss.org/jira/browse/JBRULES-2242 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert) Reporter: Mark Proctor Assignee: Mark Proctor Fix For: 5.1.0.M1 -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-79) Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction

by Martin Burger (JIRA)

Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction ---------------------------------------------------------------------------------------------------------------------------------------------- Key: JASSIST-79 URL: https://jira.jboss.org/jira/browse/JASSIST-79 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 I instrument method calls in a class called org.mozilla.javascript.Parser. 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/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper: 3200: goto -29495 Obviously, offset -29495 is an invalid opcode address. The corresponding Java code (excerpt): switch(tt) { case TokenStream.IF: { skipsemi = true; sourceAdd((char)ts.IF); int lineno = ts.getLineno(); Object cond = condition(ts); sourceAdd((char)ts.LC); sourceAdd((char)ts.EOL); Object ifTrue = statement(ts); Object ifFalse = null; if (ts.matchToken(ts.ELSE)) { sourceAdd((char)ts.RC); sourceAdd((char)ts.ELSE); sourceAdd((char)ts.LC); sourceAdd((char)ts.EOL); ifFalse = statement(ts); } sourceAdd((char)ts.RC); sourceAdd((char)ts.EOL); pn = nf.createIf(cond, ifTrue, ifFalse, lineno); break; } case TokenStream.SWITCH: { I think the break statement is related to this 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

2
8
0 / 0

[JBoss JIRA] Created: (JASSIST-67) Strange Exception: Register x contains wrong type

by kobe valiant (JIRA)

Strange Exception: Register x contains wrong type ------------------------------------------------- Key: JASSIST-67 URL: https://jira.jboss.org/jira/browse/JASSIST-67 Project: Javassist Issue Type: Bug Affects Versions: 3.8.1.GA Environment: windowsXP Reporter: kobe valiant Assignee: Shigeru Chiba Priority: Blocker ClassPool pool = new ClassPool(true); CtClass ctc = pool.makeClass("my.Clazz"); StringBuilder sb = new StringBuilder("public void test() {"); for (int i = 0; i < 1000; i++) { sb.append("for(int i=0; i<10; i++) {}"); // line 1 // sb.append("for(int i=0; i<10; i++) {int j=i;}"); // line 2 } sb.append("}"); ctc.addMethod(CtNewMethod.make(sb.toString(), ctc)); ctc.toClass().newInstance(); the code above will throw an exception: Exception in thread "main" java.lang.VerifyError: (class: my/Clazz, method: test signature: ()V) Register 0 contains wrong type But if you comment the line 1 and uncomment the line 2, there will no exception at all. -- 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

2
3
0 / 0

[JBoss JIRA] Created: (JASSIST-70) instrumenting a constructor with insertAfter() and asFinally=true

by Shigeru Chiba (JIRA)

instrumenting a constructor with insertAfter() and asFinally=true ----------------------------------------------------------------- Key: JASSIST-70 URL: https://jira.jboss.org/jira/browse/JASSIST-70 Project: Javassist Issue Type: Bug Reporter: Shigeru Chiba Assignee: Shigeru Chiba (reported by Patrice Bouillet) Instrumenting a Constructor with the insertAfter method and 'asFinally' set to true leads to a corrupt constructor. This is due to surrounding the this() and super() calls which cannot be done. Solution: I think you already know the solution, because the correct behaviour is already done for the addCatch method, so for the insertAfter method in CtBehaviour I just modified the line according to the addCatch: if (asFinally) { ca.getExceptionTable().add(getStartPosOfBody(ca), gapPos, gapPos, 0); } With this modification, the instrumentation works as expected. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JASSIST-71) Array access replacement generates invalid bytecode when padding is required

by Jason T. Greene (JIRA)

Array access replacement generates invalid bytecode when padding is required ---------------------------------------------------------------------------- Key: JASSIST-71 URL: https://jira.jboss.org/jira/browse/JASSIST-71 Project: Javassist Issue Type: Bug Reporter: Jason T. Greene Assignee: Shigeru Chiba When an array access instruction is replaced before a switch instruction, and padding is added to align the switch, the array instruction remains, which is invalid: public void test(); Code: Stack=2, Locals=2, Args_size=1 0: aconst_null 1: astore_1 2: invokestatic #17; //Method $SWITCH_TABLE$RULE_TYPE:()[I 5: aload_1 6: invokevirtual #20; //Method RULE_TYPE.ordinal:()I 9: invokestatic #67; //Method arrayReadInt:(Ljava/lang/Object;I)I 12: nop 13: iaload <=========================== INVALID!!!!!!!!!!!! 14: tableswitch{ //1 to 1 1: 32; default: 32 } 32: return This is typically caught by the bytecode verifier java.lang.VerifyError: (class: com/lm/dataModel/rules/StatusRule, method: propagateFromHereOnUpTree signature: (Lcom/lm/dataModel/ANode;Lcom/lm/dataModel/ANode$Source;Lcom/lm/dataModel/ANode$StatusValue;)Z) Unable to pop operand off an empty stack at com.lm.dataModel.ANode.setStatusValueWithPropagation(ANode.java:301) at com.lm.seem.StatusTableModel.setValueAt(StatusTableModel.java:133) -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-77) ClassFile.renameClass(s) is not processing the LocalVariableAttributes

by Adrian Brock (JIRA)

ClassFile.renameClass(s) is not processing the LocalVariableAttributes ---------------------------------------------------------------------- Key: JASSIST-77 URL: https://jira.jboss.org/jira/browse/JASSIST-77 Project: Javassist Issue Type: Bug Reporter: Adrian Brock Assignee: Shigeru Chiba ClassFile.renameClass(s) is not changing the descriptor indexes for LocalVariableAttributes. This means the types of local variables are not getting updated. See the forum thread for an example. -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-75) SerializedProxy should use TCCL in readResolve

by Ales Justin (JIRA)

SerializedProxy should use TCCL in readResolve ---------------------------------------------- Key: JASSIST-75 URL: https://jira.jboss.org/jira/browse/JASSIST-75 Project: Javassist Issue Type: Bug Reporter: Ales Justin Assignee: Shigeru Chiba Fix For: 3.10.0.GA When loading classes in SerializedProxy::readResolve we should use TCCL instaed of caller CL. e.g. ClassLoader cl = Thread.currentThread().getContextClassLoader(); cl.loadClass(name); -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JASSIST-72) Instrumenting write access using CodeConverter.replaceArrayAccess(...) causes VerifyError (Unable to pop operand off an empty stack) - buggy aastore

by Martin Burger (JIRA)

Instrumenting write access using CodeConverter.replaceArrayAccess(...) causes VerifyError (Unable to pop operand off an empty stack) - buggy aastore ---------------------------------------------------------------------------------------------------------------------------------------------------- Key: JASSIST-72 URL: https://jira.jboss.org/jira/browse/JASSIST-72 Project: Javassist Issue Type: Bug Environment: javassist 3.9.0.GA Reporter: Martin Burger Assignee: Shigeru Chiba I use Javassist to instrument class files in order to catch some runtime information. Basically, I insert probes to get information about method calls, field accesses, and so on. This includes access to arrays. Unfortunately, when I instrument array accesses using CodeConverter.replaceArrayAccess(...) the Java verifier throws an exception while loading the changed method: Unable to pop operand off an empty stack. Instrumenting array accesses is one instrumentation of many. If I disable instrumentation of array accesses, the instrumented program will run and I will get runtime information about method calls etc. As soon as I enable the instrumentation of arrays, the byte code created by javassist causes the java.lang.VerifyError mentioned above. The buggy byte code instruction seems to be: 7016: anewarray #51; //class java/lang/Object 7019: dup 7020: iconst_0 7021: iload_1 7022: bipush 56 7024: if_icmpne 7036 7027: ldc_w #5369; //String 8 7030: nop 7031: nop 7032: nop 7033: goto 7042 7036: ldc_w #5371; //String 9 7039: nop 7040: nop 7041: nop 7042: invokestatic #5373; 7045: nop 7046: aastore <-- causes VerifyError At least when executing aastore the stack is empty already. The original source code: if (base == 8 && c >= '8') { Object[] errArgs = { c == '8' ? "8" : "9" }; reportCurrentLineWarning( "msg.bad.octal.literal", errArgs); base = 10; } -- 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

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2009