SonarQube
  1. SonarQube
  2. SONAR-172

Wrong code coverage on the project commons-lang

    Details

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

      Description

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

        Issue Links

          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: