[ https://jira.jboss.org/jira/browse/JBTM-727?page=com.atlassian.jira.plugi... ] 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. -- 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

[ https://jira.jboss.org/jira/browse/JBTM-727?page=com.atlassian.jira.plugi... ] Andrew Dinn closed JBTM-727. ---------------------------- Resolution: Won't Fix emma is being dumb about exception conditions. However. making it smarter would be a lot of work and is not worth the effort for the benefit it gives us. -- 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