[JBoss JIRA] (WFLY-2899) Help and error messages in Main classes should be printed raw
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2899:
-----------------------------------------------
Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1072224|https://bugzilla.redhat.com/show_bug.cgi?id=1072224] from ON_QA to VERIFIED
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
> Key: WFLY-2899
> URL: https://issues.jboss.org/browse/WFLY-2899
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
> Fix For: 8.1.0.CR1
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins@jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
> JAVA: java
> JAVA_OPTS: -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO [stdout] (main)
> 15:31:44,918 INFO [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO [stdout] (main) where args include:
> 15:31:44,918 INFO [stdout] (main) --admin-only Set the server's running type to
> 15:31:44,919 INFO [stdout] (main) ADMIN_ONLY causing it to open
> 15:31:44,919 INFO [stdout] (main) administrative interfaces and accept
> 15:31:44,919 INFO [stdout] (main) management requests but not start other
> 15:31:44,920 INFO [stdout] (main) runtime services or accept end user
> 15:31:44,920 INFO [stdout] (main) requests.
> 15:31:44,920 INFO [stdout] (main)
> 15:31:44,920 INFO [stdout] (main)
> 15:31:44,921 INFO [stdout] (main) -b <value>, -b=<value> Set system property jboss.bind.address
> 15:31:44,921 INFO [stdout] (main) to the given value
> 15:31:44,921 INFO [stdout] (main)
> 15:31:44,921 INFO [stdout] (main)
> 15:31:44,922 INFO [stdout] (main) -b<interface>=<value> Set system property
> 15:31:44,922 INFO [stdout] (main) jboss.bind.address.<interface> to the
> 15:31:44,922 INFO [stdout] (main) given value
> 15:31:44,922 INFO [stdout] (main)
> 15:31:44,923 INFO [stdout] (main)
> 15:31:44,923 INFO [stdout] (main) -c <config>, -c=<config> Name of the server configuration file
> 15:31:44,923 INFO [stdout] (main) to use (default is "standalone.xml")
> 15:31:44,923 INFO [stdout] (main) (Same as --server-config)
> 15:31:44,924 INFO [stdout] (main)
> 15:31:44,924 INFO [stdout] (main)
> 15:31:44,924 INFO [stdout] (main) --debug [<port>] Activate debug mode with an optional
> 15:31:44,924 INFO [stdout] (main) argument to specify the port. Only
> 15:31:44,925 INFO [stdout] (main) works if the launch script supports it.
> 15:31:44,925 INFO [stdout] (main)
> 15:31:44,925 INFO [stdout] (main)
> 15:31:44,925 INFO [stdout] (main) -D<name>[=<value>] Set a system property
> 15:31:44,926 INFO [stdout] (main)
> 15:31:44,926 INFO [stdout] (main)
> 15:31:44,926 INFO [stdout] (main) -h, --help Display this message and exit
> 15:31:44,927 INFO [stdout] (main)
> 15:31:44,927 INFO [stdout] (main)
> 15:31:44,927 INFO [stdout] (main) --read-only-server-config=<config> Name of the server configuration file
> 15:31:44,927 INFO [stdout] (main) to use. This differs from
> 15:31:44,928 INFO [stdout] (main) '--server-config' and '-c' in that the
> 15:31:44,928 INFO [stdout] (main) original file is never overwritten.
> 15:31:44,928 INFO [stdout] (main)
> 15:31:44,928 INFO [stdout] (main)
> 15:31:44,929 INFO [stdout] (main) -P <url>, -P=<url>, Load system properties from the given
> 15:31:44,929 INFO [stdout] (main) --properties=<url> url
> 15:31:44,929 INFO [stdout] (main)
> 15:31:44,929 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main) -S<name>[=<value>] Set a security property
> 15:31:44,930 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main) --server-config=<config> Name of the server configuration file
> 15:31:44,931 INFO [stdout] (main) to use (default is "standalone.xml")
> 15:31:44,931 INFO [stdout] (main) (Same as -c)
> 15:31:44,931 INFO [stdout] (main)
> 15:31:44,931 INFO [stdout] (main)
> 15:31:44,932 INFO [stdout] (main) -u <value>, -u=<value> Set system property
> 15:31:44,932 INFO [stdout] (main) jboss.default.multicast.address to the
> 15:31:44,932 INFO [stdout] (main) given value
> 15:31:44,933 INFO [stdout] (main)
> 15:31:44,933 INFO [stdout] (main)
> 15:31:44,933 INFO [stdout] (main) -v, -V, --version Print version and exit
> 15:31:44,934 INFO [stdout] (main)
> 15:31:44,934 INFO [stdout] (main)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{noformat}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{noformat}
An instrumentation of this class' constructor with a try/catch block as in
{noformat}
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
{noformat}
causes an invalid class file that does not verify:
{noformat}
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
{noformat}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems to be rooted in the following bytecode sequence.
{noformat}
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
{noformat}
In contrast the reconstructed source code (the source is not available)
{noformat}
public class S {
int $;
public S(int i) {
$ = i;
}
}
{noformat}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
{noformat}
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
{noformat}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows.
{noformat}
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
{noformat}
This sequence seems easier to instrument (after the super call) with code containing a try/catch block.
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{noformat}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{noformat}
An instrumentation of this class' constructor with a try/catch block as in
{noformat}
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
{noformat}
causes an invalid class file that does not verify:
{noformat}
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
{noformat}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
{noformat}
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
{noformat}
In contrast the reconstructed source code (the source is not available)
{noformat}
public class S {
int $;
public S(int i) {
$ = i;
}
}
{noformat}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
{noformat}
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
{noformat}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows.
{noformat}
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
{noformat}
This sequence seems easier to instrument (after the super call) with code containing a try/catch block.
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> {noformat}
> Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }
> {noformat}
> An instrumentation of this class' constructor with a try/catch block as in
> {noformat}
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> {noformat}
> causes an invalid class file that does not verify:
> {noformat}
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> {noformat}
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems to be rooted in the following bytecode sequence.
> {noformat}
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> {noformat}
> In contrast the reconstructed source code (the source is not available)
> {noformat}
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> {noformat}
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> {noformat}
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> {noformat}
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows.
> {noformat}
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> {noformat}
> This sequence seems easier to instrument (after the super call) with code containing a try/catch block.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{noformat}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{noformat}
An instrumentation of this class' constructor with a try/catch block as in
{noformat}
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
{noformat}
causes an invalid class file that does not verify:
{noformat}
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
{noformat}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
{noformat}
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
{noformat}
In contrast the reconstructed source code (the source is not available)
{noformat}
public class S {
int $;
public S(int i) {
$ = i;
}
}
{noformat}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
{noformat}
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
{noformat}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows.
{noformat}
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
{noformat}
This sequence seems easier to instrument (after the super call) with code containing a try/catch block.
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{noformat}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{noformat}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> {noformat}
> Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }
> {noformat}
> An instrumentation of this class' constructor with a try/catch block as in
> {noformat}
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> {noformat}
> causes an invalid class file that does not verify:
> {noformat}
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> {noformat}
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
> {noformat}
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> {noformat}
> In contrast the reconstructed source code (the source is not available)
> {noformat}
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> {noformat}
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> {noformat}
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> {noformat}
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows.
> {noformat}
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> {noformat}
> This sequence seems easier to instrument (after the super call) with code containing a try/catch block.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal
by Markus D (JIRA)
Markus D created WFLY-3313:
------------------------------
Summary: Websocket Auth - Container is not aware of the Principal
Key: WFLY-3313
URL: https://issues.jboss.org/browse/WFLY-3313
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.1.0.CR1
Reporter: Markus D
Assignee: Jason Greene
The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal.
When an EJB is called the callerPrincipal is always anonymous.
@Resource
private SessionContext ctx;
Principal callerPrincipal = ctx.getCallerPrincipal();
Running thread here:
https://community.jboss.org/thread/240617
Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{noformat}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{noformat}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{code}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{code}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> {noformat}
> Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }
> {noformat}
> An instrumentation of this class' constructor with a try/catch block as in
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> causes an invalid class file that does not verify:
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> In contrast the reconstructed source code (the source is not available)
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-3300) Provide a way to change SSO session id cookie name. It is fixed to JSESSIONIDSSO now
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3300?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3300:
------------------------------
Fix Version/s: 8.1.0.Final
> Provide a way to change SSO session id cookie name. It is fixed to JSESSIONIDSSO now
> ------------------------------------------------------------------------------------
>
> Key: WFLY-3300
> URL: https://issues.jboss.org/browse/WFLY-3300
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Loc Ha
> Assignee: Tomaz Cerar
> Fix For: 8.1.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{{Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}}}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }
> An instrumentation of this class' constructor with a try/catch block as in
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> causes an invalid class file that does not verify:
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> In contrast the reconstructed source code (the source is not available)
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{code}
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
{code}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> {code}
> Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }
> {code}
> An instrumentation of this class' constructor with a try/catch block as in
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> causes an invalid class file that does not verify:
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> In contrast the reconstructed source code (the source is not available)
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{{Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}}}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{{dsafdsa}}
{{
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
}}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> {{Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }}}
> An instrumentation of this class' constructor with a try/catch block as in
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> causes an invalid class file that does not verify:
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> In contrast the reconstructed source code (the source is not available)
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0
[JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
by Manuel Geffken (JIRA)
[ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugi... ]
Manuel Geffken updated JASSIST-222:
-----------------------------------
Description:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{{dsafdsa}}
{{
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
}}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
was:
The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
{{
Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
Last modified May 2, 2014; size 154 bytes
MD5 checksum e79a1481a39d40004bc504cc4f7c2641
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=3, locals=2, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: putfield #13 // Field $:I
9: return
}
}}
An instrumentation of this class' constructor with a try/catch block as in
CtConstructor[] ctors = target.getDeclaredConstructors();
for (CtConstructor ctor : ctors) {
StringBuilder headerSB = new StringBuilder();
headerSB.append("{");
headerSB.append(" try {");
headerSB.append(" throw new java.lang.Exception();");
headerSB.append(" } catch(java.lang.Exception e) {}");
headerSB.append("}");
ctor.insertBeforeBody(headerSB.toString());
}
causes an invalid class file that does not verify:
Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
Last modified May 5, 2014; size 356 bytes
MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
class S
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
protected int $;
flags: ACC_PROTECTED
protected S(int);
flags: ACC_PROTECTED
Code:
stack=5, locals=3, args_size=2
0: aload_0
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
6: new #22 // class java/lang/Exception
9: dup
10: invokespecial #23 // Method java/lang/Exception."<init>":()V
13: athrow
14: astore_2
15: goto 18
18: putfield #13 // Field $:I
21: return
Exception table:
from to target type
6 14 14 Class java/lang/Exception
}
The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
1: iload_1
2: aload_0
3: invokespecial #14 // Method java/lang/Object."<init>":()V
In contrast the reconstructed source code (the source is not available)
public class S {
int $;
public S(int i) {
$ = i;
}
}
compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
Classfile S.class
Last modified May 5, 2014; size 222 bytes
MD5 checksum 9700e6458db9d62e640018421a079761
Compiled from "S.java"
public class S
SourceFile: "S.java"
minor version: 3
major version: 45
flags: ACC_SUPER
Constant pool:
...
{
int $;
flags:
public S(int);
flags: ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field $:I
9: return
}
This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
> Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-222
> URL: https://issues.jboss.org/browse/JASSIST-222
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: Unknown java compiler generating class files with major version 45, minor version 3.
> Mint Linux, JDK 1.7.
> Reporter: Manuel Geffken
> Assignee: Shigeru Chiba
> Priority: Minor
>
> The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap:
> {{dsafdsa}}
> {{
> Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class
> Last modified May 2, 2014; size 154 bytes
> MD5 checksum e79a1481a39d40004bc504cc4f7c2641
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=3, locals=2, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: putfield #13 // Field $:I
> 9: return
> }
> }}
> An instrumentation of this class' constructor with a try/catch block as in
> CtConstructor[] ctors = target.getDeclaredConstructors();
> for (CtConstructor ctor : ctors) {
> StringBuilder headerSB = new StringBuilder();
> headerSB.append("{");
> headerSB.append(" try {");
> headerSB.append(" throw new java.lang.Exception();");
> headerSB.append(" } catch(java.lang.Exception e) {}");
> headerSB.append("}");
> ctor.insertBeforeBody(headerSB.toString());
> }
> causes an invalid class file that does not verify:
> Classfile /home/geffken/git/X2Traverse/benchmarks/basic/ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S.class
> Last modified May 5, 2014; size 356 bytes
> MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1
> class S
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> protected int $;
> flags: ACC_PROTECTED
> protected S(int);
> flags: ACC_PROTECTED
> Code:
> stack=5, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> 6: new #22 // class java/lang/Exception
> 9: dup
> 10: invokespecial #23 // Method java/lang/Exception."<init>":()V
> 13: athrow
> 14: astore_2
> 15: goto 18
> 18: putfield #13 // Field $:I
> 21: return
> Exception table:
> from to target type
> 6 14 14 Class java/lang/Exception
> }
> The problem is that the operand stack can be empty when the putfield instruction is reached. The problem seems might be rooted in the following bytecode sequence.
> 1: iload_1
> 2: aload_0
> 3: invokespecial #14 // Method java/lang/Object."<init>":()V
> In contrast the reconstructed source code (the source is not available)
> public class S {
> int $;
>
> public S(int i) {
> $ = i;
> }
> }
> compiled with javac 1.7.0_51 (javac -source 1.3 -target 1.1) produces
> Classfile S.class
> Last modified May 5, 2014; size 222 bytes
> MD5 checksum 9700e6458db9d62e640018421a079761
> Compiled from "S.java"
> public class S
> SourceFile: "S.java"
> minor version: 3
> major version: 45
> flags: ACC_SUPER
> Constant pool:
> ...
> {
> int $;
> flags:
> public S(int);
> flags: ACC_PUBLIC
> Code:
> stack=2, locals=2, args_size=2
> 0: aload_0
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
> 6: putfield #2 // Field $:I
> 9: return
> }
> This version can be instrumented as shown above without problems. Here the respective bytecode sequence is as follows which seems easier to instrument with code containing a try/catch block after the super call.
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V
> 4: aload_0
> 5: iload_1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
- 1
- 0