First, you could make the instrumentation method you're calling static. I assume the verifier error you're getting is that you're trying to do a virtual method call on an uninitialized object. Calling a static method won't call a method on an object, so you'll be fine.
Second, you could do some pretty complicated stack and control flow analysis. Here's something that's legal in bytecode but not in java:
if(...) super(foo); else super(bar);
and here's something else that's legal in bytecode
void <init>(Object foo) {
aload_0
aload_1
astore_0
dup
invokespecial <init>()V
astore_1
return
}So you'll want to insert your instrumentation after both calls to super(), or something like that. One way to find all the super()'s that initialize this is to have a mechanism to determine what's on the stack before every instruction. Then, if the thing on the top of the stack at a super() call (or 1 down from the top in a super(foo) call, etc) is the same thing that was in local 0 at the beginning of the method (not necessarily now, see second example), then this super() initializes this. I don't think there is an easier way to be 100% correct. Fortunately for me (since I have to do this analysis in several places, including once where i'm doing something similar to what you're doing -- tracing execution paths), sandmark (www.cs.arizona.edu/sandmark/) has a stack simulator implementation that does just this kind of analysis.
BTW, for some reason i'm not getting Erik Corry's list posts that i see in the archive, so I'll just note here that my first code example above is an illustration of why the counter he describes won't work for general java bytecode. It seems like it might work fine for javac output though.
Also, the verification of <init> and object initialization is described in JVM spec section 4.9.4.
Nikhil C. Khedkar wrote:
Hi,
I have a query regarding the instrumentation of the
constructor. I have read all the archived mail in this
regard, but none of them served useful. I have the
same requirement i.e. put a method call at each method
start and method end. Have already put a try catch for
that. Now the task is to skip super() call before I
put my method call in the constructor.
I have a code that works for 99% of the cases.
for(int j = 1; j < ihs.length; j++)
{
if(ihs[j].getInstruction() instanceof INVOKESPECIAL)
{
il.append(ihs[j], instrumentedPatchList);
break;
}
}
It works for
1)public ABCD(XYZ obj)
{
super(obj);
}
Now a more complicated case
2)public RuleTree(int type, AppCodeAnalyzerMainPanel
mainPanel)
{
super(new DefaultTreeModel(new RuleNode("Rules")));
method1();
method2();
}
The above code fails because the Special Instruction
is not at first position. Hence A refined approach
will be to get the first instruction handle of the
second line in the constructor (first instruction
handle for method1()). Now I scan all the instructions
of the first line (super(new DefaultTreeModel(new
RuleNode("Rules")))). If there is any INVOKESPECIAL in
this list I put my code at the end of first line. This
thing works fine.
A bit more complex case
3)private XYZHandler(EventHandler commandHandler)
{
super(
ABCD.getInstance(),
Helper.getInstance(),
commandHandler,
100);
method1();
}
Now the above mentioned approach doesn't work and I
end up putting my method call before super() and get
VerifyError. Has anyone (especially the ones who have
posted those questions on constructor instrumentation
previously) been able to build a fullproof code?
Thanks,
Nikhil Khedkar
__________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone." -Jack Valenti, President, Motion Picture Association of America, Inc., before The House Subcommittee on Courts, Civil Liberties, and The Administration of Justice, August, 1982, http://cryptome.org/hrcw-hear.htm
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
