headers
Saravanan Bellan | 2 Nov 2005 08:13
Favicon

Empty Catch Blocks

Hello,

Is it possible to detect empty catch blocks using BCEL and insert
instructions for those catch blocks?

Thanks,
Permalink | Reply | 1 comment |
headers
Jacob Kjome | 2 Nov 2005 08:42
Favicon

Re: BCEL newbie question (solved!)

At 12:08 AM 10/30/2005 -0700, you wrote:
 >Jacob Kjome wrote:
 >> I am quite lost trying to figure out how to write BCel code to match the
 >> disassembled code.  Can you help out?  Here's javap's output for the
 >> static block in question...
 >
 >I am happy to help, but i'm not happy to do your work for you when it
 >appears you haven't really put much effort into doing it yourself.

I understand where you are coming from.  I've felt the same way with others 
when working on several open source projects upon which I am a 
committer.  However, in this case I'm coming from the user's point of view 
and I'm learning to empathize. I've put hours into staring at this stuff 
trying to make sense of it and what I've posted so far is as far as I've 
gotten with something that doesn't simply die at runtime, so I think you 
are being a bit presumptuous here.  And, to be honest, my goal here is not 
to learn the ins and outs of BCEL, but to get this little tiny piece of 
code working so I can move on with life and never bother with this 
gobbledygook again (no offense to those who like to write bytecode, it just 
not my cup of tea).  Like I said, I've got the class working 99% 
properly.  It seems that this 1% is taking many times the effort it took to 
do the first 99%.

 >  A good place to start learning how to write bcel code is here:
 >
 >http://jakarta.apache.org/bcel/manual.html
 >
 >you may be particularly interested in 3.3.4, which talks about
 >instruction lists.  (almost) all you have to do is write code that
 >creates an instruction list and adds to it one instruction per
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Huntwork | 6 Nov 2005 06:19

Re: BCEL newbie question (solved!)

On 11/2/05, Jacob Kjome <hoju <at> visi.com> wrote:
>
> [...]I really don't have the first clue about this stuff and am happy to
> have
> the code generated for me. But just for giggles, how about this...
>
> The instruction lists append stuff and return instruction
> handles. Great. But if this appending is akin to something like a
> StringBuffer, order matters. Is that the case with Instruction lists? If
> so, how do I deal with this?...

Order definitely matters. You can append a forward branch (like 4: ifnonnull
32 in your example) by simply inserting the branch instruction when you come
to it in the code segment you're generating, but initially give the branch a
null target. Then you can set the target of the branch instruction after
inserting the target instruction. For example, if you want to generate this
code:

0: aconst_null[1](1)
1: ifnonnull[199](3) -> nop
4: nop[0](1)
5: return[177](1)

you can use this code:
InstructionList il = new InstructionList();
il.append(new ACONST_NULL());
IFNONNULL inn = new IFNONNULL(null); //create the branch but don't set a
target yet
il.append(inn); // append the branch
InstructionHandle ih = il.append(new NOP()); //append the target
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Huntwork | 6 Nov 2005 06:47

Re: Empty Catch Blocks

yes you can, mostly. Check out disassembly for an empty catch block:

public void testFoo();
Signature: ()V
Code:
0: aload_0
1: ifnull 16
4: new #16; //class java/lang/RuntimeException
7: dup
8: invokespecial #17; //Method java/lang/RuntimeException."<init>":()V
11: athrow
12: goto 16
15: astore_1
16: return
Exception table:
from to target type
0 15 15 Class java/lang/RuntimeException

Here's the source code:
public void testFoo() {
try { if(this != null) throw new RuntimeException(); }
catch(RuntimeException e) {}
}

You can find empty catch blocks by finding exception ranges where the last
instruction targets the instruction after the handler instruction and where
the handler instruction is either astore or pop. In this example, the
process would be as follows: look at the exception handler table. notice
that an exception range ends at 15, which means the last instruction in the
range is 12: goto 16 (since the range is exclusive of the range end). Then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Silveira Neves | 9 Nov 2005 18:23
Picon
Picon
Favicon

Build a instruction trace with BCEL

Hi!

My name is Bruno Neves, I am a Phd. Student at Federal University Of Rio 
Grande.
I need build a instrumenter using  BCEL to generate a instrucion 
(bytecode) trace file of  some applications. So, I'd like to know if 
someone have already contructed this kind of tool using BCEL and can 
give me the code or some (suggestion) to help me fix my code (attached 
file).

I have interest in see more small examples of using BCEL too.

Tank you of any help!

regards,

Bruno.

________________

import java.io.*;
import java.util.Iterator;
import org.apache.bcel.classfile.*;
import org.apache.bcel.generic.*;
import org.apache.bcel.Repository;
import org.apache.bcel.util.InstructionFinder;

public class MakeTrace {

    static ClassParser p;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Huntwork | 9 Nov 2005 19:19

Re: Build a instruction trace with BCEL

Hi bruno. We wrote something along these lines for the execution path
watermark implemented in sandmark. Unfortunately, that code is only in cvs,
but maybe someone on the sandmark mailing list (
sandmark-users <at> listserv.arizona.edu) can hook you up somehow. My
recollection is that we collected a trace of what basic blocks were executed
(from which a full instruction trace can be extracted) by adding something
like to following code to each block.

BasicBlockLog.log(blockNum)

where each block was instrumented to pass a different number as blockNum and
BasicBlockLog was a class that we inserted into the instrumented app that
had a thread local block trace (i.e., a List<Integer>) to which
BasicBlockLog.log would add. I think BasicBlockLog would also start up a
thread that would write logs to disk when they got too big. By instrumenting
in this way, instrumented apps could actually run in reasonable times and
the logs were small enough to be processed in very reasonable times.

Your code below is a good start but has a couple problems. First, i don't
think your trace will be correct if any kind of branches occur because the
branch will target the same instruction it did before you instrumented, thus
skipping your println code. You need to redirect branch targets to the
instrumentation code to make this work. This is in fact a PITA. For example,
if your original code is:

goto nop
nop

and you instrument it like this (which is how you're currently doing it i
think):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mariano Achaval | 23 Nov 2005 17:55

JustIce problem with

I trying to use the JustIce with 1.5 classes but i get this error

Operand of LDC or LDC_W must be one of CONSTANT_Integer, CONSTANT_Float or
CONSTANT_String, but is 'CONSTANT_Class[7](name_index = 214)'.

I have search and this seems to be the reason
JVM spec has changed so that LDC/LDC_W can load CONSTANT_Class constants - those
instructions are issued by the 1.5 compiler now, when you use a class literal. 
So it seems that it must be added to the options
At Pass3aVerifier
public void visitLDC(LDC o){
indexValid(o, o.getIndex());
Constant c = cpg.getConstant(o.getIndex());
if (! ( (c instanceof ConstantInteger)	||
	(c instanceof ConstantFloat) 		||
(c instanceof ConstantString) ) ){
constraintViolated(o, "Operand of LDC or LDC_W must be one of CONSTANT_Integer,
CONSTANT_Float or CONSTANT_String, but is '"+c+"'.");
			}
		}

As you can see the ConstantClass was not added
Saluts
Mariano A.
Permalink | Reply | 1 comment |
headers
Dave Brosius | 24 Nov 2005 04:25
Picon
Favicon

Re: JustIce problem with

If you wouldn't mind, please post a bug to: 
http://issues.apache.org/bugzilla/

if you have a simple class that shows the problem, please post that too.

Thanks!
-dave

----- Original Message ----- 
From: "Mariano Achaval" <machaval <at> fuegolabs.com>
To: <bcel-user <at> jakarta.apache.org>
Sent: Wednesday, November 23, 2005 11:55 AM
Subject: JustIce problem with

>I trying to use the JustIce with 1.5 classes but i get this error
>
> Operand of LDC or LDC_W must be one of CONSTANT_Integer, CONSTANT_Float or
> CONSTANT_String, but is 'CONSTANT_Class[7](name_index = 214)'.
>
> I have search and this seems to be the reason
> JVM spec has changed so that LDC/LDC_W can load CONSTANT_Class constants - 
> those
> instructions are issued by the 1.5 compiler now, when you use a class 
> literal.
> So it seems that it must be added to the options
> At Pass3aVerifier
> public void visitLDC(LDC o){
> indexValid(o, o.getIndex());
> Constant c = cpg.getConstant(o.getIndex());
> if (! ( (c instanceof ConstantInteger) ||
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick O'shea | 28 Nov 2005 09:58
Favicon

next release date ?

Hi 

Could someone give me a ballpark figure of when the next release of bcel 
will be?

thanks
Patrick O'Shea
Permalink | Reply | 2 comments |
headers
Torsten Curdt | 28 Nov 2005 19:52
Picon
Favicon
Gravatar

Re: next release date ?

> Could someone give me a ballpark figure of when the next release of  
> bcel
> will be?

Do you just want to see a bug fix release? Or are after something more?

cheers
--
Torsten
Permalink | Reply | 1 comment |

Gmane