[Soot-list] Bug in ASTCleaner

[Steffen Pingel]

Hi,

I have observed a NoSuchElementException that is caused by a bug in ASTCleaner 
while trying to decompile Soot [1]. I have attached a simple example that 
demonstrats the bug [2]. Here is the stack trace:

Exception in thread "main" java.util.NoSuchElementException
        at java.util.AbstractList$Itr.next(AbstractList.java:427)
        at 
soot.dava.toolkits.base.AST.transformations.OrAggregatorThree.createNewNodeBody(OrAggregatorThree.java:209)
        at 
soot.dava.toolkits.base.AST.transformations.OrAggregatorThree.checkAndTransform(OrAggregatorThree.java:75)
        at 
soot.dava.toolkits.base.AST.transformations.ASTCleaner.normalRetrieving(ASTCleaner.java:114)
        at 
soot.dava.toolkits.base.AST.analysis.DepthFirstAdapter.caseASTIfNode(DepthFirstAdapter.java:180)
        at soot.dava.internal.AST.ASTIfNode.apply(ASTIfNode.java:145)
[...]

The exception is caused is by the loop in ASTCleaner.normalRetrieving():

	[...]
	Iterator it = ((List) subBody).iterator();
			
	int nodeNumber=0;
	//go over the ASTNodes in this subBody and apply
	while (it.hasNext()){
		[...]
		if(temp instanceof ASTIfNode){
			if(it.hasNext()){
				ASTNode nextNode = (ASTNode)((List)subBody).get(nodeNumber+1);
				if(nextNode instanceof ASTIfNode){
					OrAggregatorThree.checkAndTransform(node,(ASTIfNode)temp,
							(ASTIfNode)nextNode,nodeNumber,subBodyNumber);
				}
			}
		}
		temp.apply(this);
		nodeNumber++;
	}
	[...]

The call to OrAggregatorThree.checkAndTransform() will replace the body of 
node. Unfortunatelly normalRetrieving() still iterates over the old body 
(subBody) which has different nodes. In this case subBody contains more nodes 
than the acctual node, since OrAggregatorThree combines two If statements to 
a single If statement, eventually causing a NoSuchElement exception, because 
of a wrong nodeNumber offset. 

I can't think of an easy fix, except for disabling OrAggregatorThree for now.

Steffen


[1] Soot was compiled and run with Eclipse 3.1.1 using JDK 1.4.2_06
[2] Running "soot.Main -f d soot.dava.internal.SET.SETStatementSequenceNode" 
will also trigger the bug

-- 
Steffen Pingel - steffenp at gmx.de - http://steffenpingel.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Example6.java
Type: text/x-java
Size: 580 bytes
Desc: not available
Url : http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20060114/0104cd32/Example6.bin