SonarQube
  1. SonarQube
  2. SONAR-172

Wrong code coverage on the project commons-lang

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: Metrics
    • Labels:
      None

      Description

      Calculated coverage is 0.4%, whereas it should be at least 80% !

        Activity

        Hide
        Julien Lancelot added a comment - - edited

        On windows system, there's no problem. The code coverage is about 92%, even after executing sonar many times.

        On linux (Ubuntu), the code coverage is at 100%, and after executing sonar many times, the value alternate between 0% and 100%.
        During sonar collect, there's a exception raised many times when cobertura try to work on cobertura.ser.

        Here's is the trace :

        ---------------------------------------------------------------------------------------------------------------------------------
        Unable to get lock on /home/julien/Bureau/dev/projects/commons-lang/trunk/target/cobertura/cobertura.ser.lock: null
        This is known to happen on Linux kernel 2.6.20.
        Make sure cobertura.jar is in the root classpath of the jvm
        process running the instrumented code.  If the instrumented code
        is running in a web server, this means cobertura.jar should be in
        the web server's lib directory.
        Don't put multiple copies of cobertura.jar in different WEB-INF/lib directories.
        Only one classloader should load cobertura.  It should be the root classloader.
        ---------------------------------------
        ---------------------------------------
        java.lang.reflect.InvocationTargetException
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                at java.lang.reflect.Method.invoke(Method.java:597)
                at net.sourceforge.cobertura.util.FileLocker.lock(FileLocker.java:124)
                at net.sourceforge.cobertura.coveragedata.ProjectData.saveGlobalProjectData(ProjectData.java:234)
                at net.sourceforge.cobertura.coveragedata.SaveTimer.run(SaveTimer.java:31)
                at java.lang.Thread.run(Thread.java:619)
        Caused by: java.nio.channels.OverlappingFileLockException
                at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(FileChannelImpl.java:1173)
                at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(FileChannelImpl.java:1075)
                at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:837)
                at java.nio.channels.FileChannel.lock(FileChannel.java:860)
                ... 8 more
        ---------------------------------------------------------------------------------------------------------------------------------
        

        I update the kernel to 2.6.22-14 version, but it changed nothing.

        Show
        Julien Lancelot added a comment - - edited On windows system, there's no problem. The code coverage is about 92%, even after executing sonar many times. On linux (Ubuntu), the code coverage is at 100%, and after executing sonar many times, the value alternate between 0% and 100%. During sonar collect, there's a exception raised many times when cobertura try to work on cobertura.ser. Here's is the trace : --------------------------------------------------------------------------------------------------------------------------------- Unable to get lock on /home/julien/Bureau/dev/projects/commons-lang/trunk/target/cobertura/cobertura.ser.lock: null This is known to happen on Linux kernel 2.6.20. Make sure cobertura.jar is in the root classpath of the jvm process running the instrumented code. If the instrumented code is running in a web server, this means cobertura.jar should be in the web server's lib directory. Don't put multiple copies of cobertura.jar in different WEB-INF/lib directories. Only one classloader should load cobertura. It should be the root classloader. --------------------------------------- --------------------------------------- java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at net.sourceforge.cobertura.util.FileLocker.lock(FileLocker.java:124) at net.sourceforge.cobertura.coveragedata.ProjectData.saveGlobalProjectData(ProjectData.java:234) at net.sourceforge.cobertura.coveragedata.SaveTimer.run(SaveTimer.java:31) at java.lang. Thread .run( Thread .java:619) Caused by: java.nio.channels.OverlappingFileLockException at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(FileChannelImpl.java:1173) at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(FileChannelImpl.java:1075) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:837) at java.nio.channels.FileChannel.lock(FileChannel.java:860) ... 8 more --------------------------------------------------------------------------------------------------------------------------------- I update the kernel to 2.6.22-14 version, but it changed nothing.
        Hide
        Simon Brandhof added a comment -

        My project is reseted and instrumented several times, that's why the final code coverage is 100%. That's exactly the error described at MCOBERTURA-56.

        Show
        Simon Brandhof added a comment - My project is reseted and instrumented several times, that's why the final code coverage is 100%. That's exactly the error described at MCOBERTURA-56.
        Hide
        Simon Brandhof added a comment -

        Waiting for a cobertura fix.

        Show
        Simon Brandhof added a comment - Waiting for a cobertura fix.
        Hide
        Wouter de Vaal added a comment - - edited

        Here's a workaround that worked for me (got this error on FreeBSD too):

        			<plugin>
        				<groupId>org.apache.maven.plugins</groupId>
        				<artifactId>maven-surefire-plugin</artifactId>
        				<version>2.4.3</version>
        				<configuration>
        					<systemProperties>
        						<property>
        							<name>cobertura.use.java.nio</name>
        							<value>false</value>
        						</property>
        					</systemProperties>
        				</configuration>
        			</plugin>
        
        Show
        Wouter de Vaal added a comment - - edited Here's a workaround that worked for me (got this error on FreeBSD too): <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.4.3</version> <configuration> <systemProperties> <property> <name>cobertura.use.java.nio</name> <value> false </value> </property> </systemProperties> </configuration> </plugin>
        Hide
        Freddy Mallet added a comment -

        Thanks a lot for this workaround. I've updated the Sonar FAQ and I'm going to close this ticket.

        Show
        Freddy Mallet added a comment - Thanks a lot for this workaround. I've updated the Sonar FAQ and I'm going to close this ticket.

          People

          • Assignee:
            Unassigned
            Reporter:
            Simon Brandhof
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: