[jbossts-issues] [JBoss JIRA] Commented: (JBTM-727) Emma coverage missing some method invocations

[Andrew Dinn (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBTM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12519502#action_12519502 ] 

Andrew Dinn commented on JBTM-727:
----------------------------------

Hmm, interesting! The coverage result is maybe half right and half wrong.

Here is the source and the corresponding instrumented bytecode for the ServerOSITopLevelAction.commit()

public void commit () throws SystemException, NotPrepared, HeuristicRollback, HeuristicMixed, HeuristicHazard
    {
	if (jtsLogger.logger.isDebugEnabled())
	{
	    jtsLogger.logger.debug(DebugLevel.FUNCTIONS, VisibilityLevel.VIS_PUBLIC,
					       com.arjuna.ats.jts.logging.FacilityCode.FAC_OTS, "ServerOSITopLevelAction::commit for "+_theUid);
	}
	OTIDMap.remove(get_uid());
        commit();
    }


public void commit()   throws org.omg.CORBA.SystemException, org.omg.CosTransactions.NotPrepared, org.omg.CosTransactions.HeuristicRollback, org.omg.CosTransactions.HeuristicMixed, org.omg.CosTransactions.HeuristicHazard;
  Code:
   0:	getstatic	#129; //Field $VRc:[[Z
   3:	dup
   4:	ifnonnull	11
   7:	pop
   8:	invokestatic	#139; //Method $VRi:()[[Z
   11:	iconst_3
   12:	aaload
   13:	astore_1
   14:	getstatic	#2; //Field com/arjuna/ats/jts/logging/jtsLogger.logger:Lcom/arjuna/common/util/logging/LogNoi18n;
   17:	invokeinterface	#3,  1; //InterfaceMethod com/arjuna/common/util/logging/LogNoi18n.isDebugEnabled:()Z
   22:	aload_1
   23:	iconst_0
   24:	iconst_1
   25:	bastore
   26:	ifeq	72
   29:	getstatic	#2; //Field com/arjuna/ats/jts/logging/jtsLogger.logger:Lcom/arjuna/common/util/logging/LogNoi18n;
   32:	ldc2_w	#16; //long 16l
   35:	ldc2_w	#4; //long 4l
   38:	ldc2_w	#6; //long 256l
   41:	new	#8; //class java/lang/StringBuilder
   44:	dup
   45:	invokespecial	#9; //Method java/lang/StringBuilder."<init>":()V
   48:	ldc	#26; //String ServerOSITopLevelAction::commit for 
   50:	invokevirtual	#11; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   53:	aload_0
   54:	getfield	#19; //Field _theUid:Lcom/arjuna/ats/arjuna/common/Uid;
   57:	invokevirtual	#20; //Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;
   60:	invokevirtual	#14; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   63:	invokeinterface	#15,  8; //InterfaceMethod com/arjuna/common/util/logging/LogNoi18n.debug:(JJJLjava/lang/String;)V
   68:	aload_1
   69:	iconst_1
   70:	iconst_1
   71:	bastore
   72:	aload_0
   73:	invokevirtual	#21; //Method get_uid:()Lcom/arjuna/ats/arjuna/common/Uid;
   76:	invokestatic	#22; //Method com/arjuna/ats/internal/jts/interposition/resources/osi/OTIDMap.remove:(Lcom/arjuna/ats/arjuna/common/Uid;)Z
   79:	pop
   80:	aload_0
   81:	invokespecial	#27; //Method com/arjuna/ats/internal/jts/orbspecific/interposition/resources/strict/ServerStrictTopLevelAction.commit:()V
   84:	aload_1
   85:	iconst_2
   86:	iconst_1
   87:	bastore
   88:	return

Ok, I know that's a lot of wtf but the important bit is those sequences in the form

   aload_1
   iconst_n
   iconst_1
   bastore

They set flags in a boolean[] which indicate that a specific path segment through the code has been traversed. In this case emma sees 3 segments:

method entry to if (debugEnabled)
inside if (debugEnabled)
endif (debugEnabled) to return

Each segment is tailed by one of those array flag writes which records that the preceding segment has actually been traversed.

Each segment is supposed to be a  basic block i.e. it contains no control-flow. However, emma has a flawed concept of 'basic block' because the last segment contains impllicit control flow due to the fact that super.commit() can throw an exception. (This test -- and, it appears, all other tests -- does in fact throw an exception in commit() so the results indicate that OTIDMap.remove() and super.commit() have not been successfully called. By contrast, it appears that there are cases where rollback does not throw an exception which explains why it gets more full coverage.)

Strictly, the last segment in commit should be split in two before the call to super.commit. If this were done then the test would then show that the call to OTIDMap.remove() was made and returned normally but that the call  to super.commit() was made but did not complete.

I say that emma is _maybe_ half right but that's also questionable. The call to  commit was made but did not complete. So, the line for commit probably should be shown as covered and the last line of the method (where the implicit return happens) should be shown as not covered. In order to do this emma probably needs to inject the code which set flags at the _start_ of basic blocks. That would have to include a new basic block which includes the implicit return following super.commit().

So, two things to patch in emma  to fix this one. I'll stick them  on the list of things to patch and also post a defect for the emma maintainer.



> Emma coverage missing some method invocations
> ---------------------------------------------
>
>                 Key: JBTM-727
>                 URL: https://jira.jboss.org/jira/browse/JBTM-727
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>            Assignee: Andrew Dinn
>             Fix For: 4.11.0
>
>
> There are some class that emma says don't have coverage and yet there are tests that do cover them (and I have confirmed the methods get called). For instance ServerTopLevelOSIActionUnitTest which covers ServerOSITopLevelAction. The commit and rollback methods are invoked, yet emma misses them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira