0
J'utilise ASM pour faire de l'instrumentation bytecode pour les programmes Java. Ce que je fais est simple - Lors de l'instrumentation d'une méthode, si l'instruction est un PUTFIELD, faites simplement un DUP_X1 juste avant l'instruction, puis visitez le PUTFIELD et injectez un appel de fonction avec un argument qui inclut l'entrée DUP'ed stack.Instrumentation bytecode générant une erreur java verifier
public void visitFieldInsn(
int opcode,
String owner, // owner of this field...
String name,
String desc) {
boolean did_dup = false;
if(opcode == Opcodes.PUTFIELD) {
if(!owner.equals("java/lang/System")) {
if (desc.startsWith("L")) {
mv.visitInsn(Opcodes.DUP_X1);
did_dup = true;
}
}
}
mv.visitFieldInsn(opcode, owner, name, desc);
if (did_dup) {
mv.visitVarInsn(Opcodes.ALOAD, 0);
mv.visitMethodInsn(Opcodes.INVOKESTATIC, "com/amir/ASide", "updateG", "(Ljava/lang/Object;Ljava/lang/Object;)V");
}
}
Le code ressemble à ceci AVANT et APRÈS l'instrumentation, respectivement:
public void setA(ClassA classa)
{
refA = classa;
eyeColor = classa.eyeColor;
}
public void setA(ClassA classa)
{
ASide.updateG(refA = classa, this);
ASide.updateG(eyeColor = classa.eyeColor, this);
}
Mais quand je lance le code instrumenté, je reçois:
java.lang.VerifyError: Attendons de trouver objet/tableau sur la pile
Pouvez-vous offrir de l'aide à ce sujet?
Etes-vous sûr qu'il se plaint de la méthode setA modifiée? –
Il ne se plaint pas de la méthode setA Martin - c'est une observation vive. Pensez-vous que je devrais regarder dans la méthode réelle dont il se plaint? Il semble être lié aux classes internes. –
Cela a quelque chose à voir avec les classes internes - mais je ne sais pas pourquoi cela devrait importer –