[Javassist Development] - Problem with CodeIterator.newOffset()
by Alasdair Mackintosh
Alasdair Mackintosh [http://community.jboss.org/people/alasdair] created the discussion
"Problem with CodeIterator.newOffset()"
To view the discussion, visit: http://community.jboss.org/message/547652#547652
--------------------------------------------------------------
I've been having some problems with Javassist which I think I've finally narrowed down to the way that "goto" offsets are updated when you insert new bytecode. It looks as though newOffset is not correctly handling the case when you insert new opcodes at a location which already contains a "goto" opcode.
private static int newOffset(int i, int offset, int where,
int gapLength, boolean exclusive) {
int target = i + offset;
if (i < where) {
if (where < target || (exclusive && where == target))
offset += gapLength;
}
else if (i == where) {
if (target < where && exclusive)
offset -= gapLength;
else if (where < target && !exclusive)
offset += gapLength;
}
else
if (target < where || (!exclusive && where == target))
offset -= gapLength;
return offset;
}
And I think the middle clause should look like this:
else if (i == where) {
if (target < where)
offset -= gapLength;
}
If you insert new bytecode at a location containing a goto (so that the goto opcode is about to be moved forward by n bytes) then you need to modify the offset if it's negative, but keep it the same if it's already positive.
I've made this change and re-run the tests, which all pass, but I wanted to check to see if this fix looks reasonable.
I don't have a simple test case that shows the problem. I found this when I tried to run my testing framework ThreadWeaver ( http://code.google.com/p/thread-weaver/ http://code.google.com/p/thread-weaver/) with the latest version of Javassist. The problem can be demonstrated by building ThreadWeaver and running the unit tests.
If you want a simpler test case let me know. I think THreadWeaver triggered this because it uses Javassist to insert lots of small code snippets into the instrumented bytecode.
Alasdair
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547652#547652]
Start a new discussion in Javassist Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[Javassist Development] - Problem in CodeIterator.newOffset()
by Alasdair Mackintosh
Alasdair Mackintosh [http://community.jboss.org/people/alasdair] created the discussion
"Problem in CodeIterator.newOffset()"
To view the discussion, visit: http://community.jboss.org/message/547651#547651
--------------------------------------------------------------
I've been having some problems with Javassist which I think I've finally narrowed down to the way that
"goto" offsets are updated when you insert new bytecode. It looks as though newOffset is not correctly
handling the case when you insert new opcodes at a location which already contains a "goto" opcode.
The code for newOffset() looks like this:
private static int newOffset(int i, int offset, int where,
int gapLength, boolean exclusive) {
int target = i + offset;
if (i < where) {
if (where < target || (exclusive && where == target))
offset += gapLength;
}
else if (i == where) {
if (target < where && exclusive)
offset -= gapLength;
else if (where < target && !exclusive)
offset += gapLength;
}
else
if (target < where || (!exclusive && where == target))
offset -= gapLength;
return offset;
}
And I think the middle clause should look like this:
else if (i == where) {
if (target < where)
offset -= gapLength;
}
If you insert new bytecode at a location containing a goto (so that the goto opcode is about to be moved forward by n bytes) then you need to modify the offset if it's negative, but keep it the same if it's already positive.
I've made this change and re-run the tests, which all pass, but I wanted to check to see if this fix looks reasonable.
I don't have a simple test case that shows the problem. I found this when I tried to run my testing framework ThreadWeaver ( http://code.google.com/p/thread-weaver/ http://code.google.com/p/thread-weaver/) with the latest version of Javassist. The problem can be demonstrated by building ThreadWeaver and running the unit tests.
If yuo want a simpler test case let me know. I think THreadWeaver triggered this because it uses Javassist to insert lots of small code snippets into the instrumented bytecode.
Alasdair
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547651#547651]
Start a new discussion in Javassist Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years