feedback-to-code/mozzarella huggingface dataset:
Repository: square/retrofit
Issue: Use Moshi's JsonAdapter.serializeNulls() method.
Labels: Blocked

Once it's released.

https://github.com/square/moshi/pull/238

Issue comments:

Pull request review comments:
Useless, but other methods do the same, and it's best for symmetry here, I believe.

Patch that resolved the issue:
diff --git a/pom.xml b/pom.xml
index a2309e1769..4dd4aa6ab7 100644
--- a/pom.xml
+++ b/pom.xml
@@ -63,7 +63,7 @@
     <jackson.version>2.7.2</jackson.version>
     <wire.version>2.2.0</wire.version>
     <simplexml.version>2.7.1</simplexml.version>
-    <moshi.version>1.3.0</moshi.version>
+    <moshi.version>1.4.0</moshi.version>
 
     <!-- Sample Dependencies -->
     <jsoup.version>1.7.3</jsoup.version>
diff --git a/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiConverterFactory.java b/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiConverterFactory.java
index 0b95d19518..311d76d0dc 100644
--- a/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiConverterFactory.java
+++ b/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiConverterFactory.java
@@ -94,6 +94,9 @@ public MoshiConverterFactory withNullSerialization() {
     if (failOnUnknown) {
       adapter = adapter.failOnUnknown();
     }
+    if (serializeNulls) {
+      adapter = adapter.serializeNulls();
+    }
     return new MoshiResponseBodyConverter<>(adapter);
   }
 
@@ -106,7 +109,10 @@ public MoshiConverterFactory withNullSerialization() {
     if (failOnUnknown) {
       adapter = adapter.failOnUnknown();
     }
-    return new MoshiRequestBodyConverter<>(adapter, serializeNulls);
+    if (serializeNulls) {
+      adapter = adapter.serializeNulls();
+    }
+    return new MoshiRequestBodyConverter<>(adapter);
   }
 
   private static Set<? extends Annotation> jsonAnnotations(Annotation[] annotations) {
diff --git a/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiRequestBodyConverter.java b/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiRequestBodyConverter.java
index 5e59b17fed..edbcf243e5 100644
--- a/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiRequestBodyConverter.java
+++ b/retrofit-converters/moshi/src/main/java/retrofit2/converter/moshi/MoshiRequestBodyConverter.java
@@ -27,17 +27,14 @@ final class MoshiRequestBodyConverter<T> implements Converter<T, RequestBody> {
   private static final MediaType MEDIA_TYPE = MediaType.parse("application/json; charset=UTF-8");
 
   private final JsonAdapter<T> adapter;
-  private final boolean serializeNulls;
 
-  MoshiRequestBodyConverter(JsonAdapter<T> adapter, boolean serializeNulls) {
+  MoshiRequestBodyConverter(JsonAdapter<T> adapter) {
     this.adapter = adapter;
-    this.serializeNulls = serializeNulls;
   }
 
   @Override public RequestBody convert(T value) throws IOException {
     Buffer buffer = new Buffer();
     JsonWriter writer = JsonWriter.of(buffer);
-    writer.setSerializeNulls(serializeNulls);
     adapter.toJson(writer, value);
     return RequestBody.create(MEDIA_TYPE, buffer.readByteString());
   }


Test patch:
Repository: square/retrofit
Issue: Deserialisation of untrusted data in jackson-databind  [,2.9.7)

Snyk analysis flags up security vulnerabilities in com.squareup.retrofit2:converter-jackson:2.5.0 due to the dependency on com.fasterxml.jackson.core:jackson-databind@2.9.4

https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451

Could you please upgrade to jackson-databind@2.9.7?

Issue comments:
We can update, sure, but we don't do releases for updating converter
dependencies. If you need a newer version the consumer should specify it.

On Tue, Dec 18, 2018, 11:07 AM dGhlb3ds <notifications@github.com wrote:

> Snyk analysis flags up security vulnerabilities in
> com.squareup.retrofit2:converter-jackson:2.5.0 due to the dependency on
> com.fasterxml.jackson.core:jackson-databind@2.9.4
>
> https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451
>
> Could you please upgrade to jackson-databind@2.9.7?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/square/retrofit/issues/2991>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAEEEQHAhV1oM95KCdnnLVJ2IUgxciCkks5u6RKngaJpZM4ZYmmM>
> .
>

How does the consumer specify the newer version ? 
They declare it explicitly as a dependency and their dependency tool will
resolve the newer version. Basically the same as how you declare any other
dependency.

On Fri, Feb 15, 2019, 3:16 AM pavankumarvvijapur <notifications@github.com
wrote:

> How does the consumer specify the newer version ?
>
> —
> You are receiving this because you commented.
>
>
> Reply to this email directly, view it on GitHub
> <https://github.com/square/retrofit/issues/2991#issuecomment-463947736>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAEEEYNVGNNO8M58UENlY2PVFkHCBTDAks5vNmzYgaJpZM4ZYmmM>
> .
>


Pull request review comments:

Patch that resolved the issue:
diff --git a/pom.xml b/pom.xml
index 85a3ceebfe..d1ac09dba3 100644
--- a/pom.xml
+++ b/pom.xml
@@ -62,7 +62,7 @@
     <!-- Converter Dependencies -->
     <gson.version>2.8.2</gson.version>
     <protobuf.version>3.0.0</protobuf.version>
-    <jackson.version>2.9.4</jackson.version>
+    <jackson.version>2.9.8</jackson.version>
     <wire.version>2.2.0</wire.version>
     <simplexml.version>2.7.1</simplexml.version>
     <moshi.version>1.5.0</moshi.version>


Test patch:
Repository: square/retrofit
Issue: HttpException.response() should be marked w/ @Nullable
Labels: Bug

What kind of issue is this?

 - [x] Bug report

Code for that method in Retrofit2 2.5 is:

```
/**
   * The full HTTP response. This may be null if the exception was serialized.
   */
  public Response<?> response() {
    return response;
  }
```

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/retrofit/src/main/java/retrofit2/HttpException.java b/retrofit/src/main/java/retrofit2/HttpException.java
index c01f97dfe8..f53e76e782 100644
--- a/retrofit/src/main/java/retrofit2/HttpException.java
+++ b/retrofit/src/main/java/retrofit2/HttpException.java
@@ -15,6 +15,8 @@
  */
 package retrofit2;
 
+import javax.annotation.Nullable;
+
 import static retrofit2.Utils.checkNotNull;
 
 /** Exception for an unexpected, non-2xx HTTP response. */
@@ -48,7 +50,7 @@ public String message() {
   /**
    * The full HTTP response. This may be null if the exception was serialized.
    */
-  public Response<?> response() {
+  public @Nullable Response<?> response() {
     return response;
   }
 }


Test patch:
Repository: square/retrofit
Issue: 2.9 snapshots ship with byte code level 58

What kind of issue is this?

 - [ ] Question. This issue tracker is not the place for questions. If you want to ask how to do
       something, or to understand why something isn't working the way you expect it to, use Stack
       Overflow. https://stackoverflow.com/questions/tagged/retrofit

 - [x] Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests
       get fixed. Here’s an example: https://gist.github.com/swankjesse/6608b4713ad80988cdc9

 - [ ] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
       already exists! Don’t send pull requests to implement new features without first getting our
       support. Sometimes we leave features out on purpose to keep the project small.

```
➜  retrofit-2.8.1 javap -v retrofit2.Retrofit\$Builder|grep major          
  major version: 52
➜  retrofit-2.9.SNAPSPOT javap -v retrofit2.Retrofit\$Builder|grep major         
  major version: 58
```

Based on the ASG thread, looks like snapshots are shipping w/ Java 1.4 byte code unintentionally.
It would be nice to get them back to 52 so that i can use snapshot version :)

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/build.gradle b/build.gradle
index d3dd0930dc..847eb2adc5 100644
--- a/build.gradle
+++ b/build.gradle
@@ -59,6 +59,12 @@ subprojects {
     jcenter()
   }
 
+  tasks.withType(JavaCompile).configureEach { task ->
+    task.options.encoding = 'UTF-8'
+    task.sourceCompatibility = JavaVersion.VERSION_1_8
+    task.targetCompatibility = JavaVersion.VERSION_1_8
+  }
+
   // Error-prone only works on JDK 11 or older currently.
   if (!Jvm.current().javaVersion.isJava12Compatible()) {
     apply plugin: 'net.ltgt.errorprone'
@@ -69,10 +75,6 @@ subprojects {
     }
 
     tasks.withType(JavaCompile).configureEach { task ->
-      task.options.encoding = 'UTF-8'
-      task.sourceCompatibility = JavaVersion.VERSION_1_8
-      task.targetCompatibility = JavaVersion.VERSION_1_8
-
       task.options.errorprone {
         excludedPaths = '.*/build/generated/source/proto/.*'
         check('MissingFail', CheckSeverity.ERROR)


Test patch:
Repository: square/retrofit
Issue: Platform detection fails in Android Studio 4.1 Canary 8

What kind of issue is this?

 - [ ] Question. This issue tracker is not the place for questions. If you want to ask how to do
       something, or to understand why something isn't working the way you expect it to, use Stack
       Overflow. https://stackoverflow.com/questions/tagged/retrofit

 - [x] Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests
       get fixed. Here’s an example: https://gist.github.com/swankjesse/6608b4713ad80988cdc9

 - [ ] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
       already exists! Don’t send pull requests to implement new features without first getting our
       support. Sometimes we leave features out on purpose to keep the project small.

I have an IntelliJ plugin that started crashing in AndroidStudio Canary 4.1.
full exception:
https://github.com/yigit/ArtifactFinder/issues/16

Seems like in 4.1, `Class.forName("android.os.Build") does not fail anymore and then eventually causes a different exception:
https://github.com/square/retrofit/blob/master/retrofit/src/main/java/retrofit2/Platform.java#L43

```
java.lang.UnsatisfiedLinkError: android.os.SystemProperties.native_get(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
	at android.os.SystemProperties.native_get(Native Method)
	at android.os.SystemProperties.get(SystemProperties.java:129)
	at android.os._Original_Build.getString(Build.java:1265)
	at android.os._Original_Build.<clinit>(Build.java:51)
	at android.os._Original_Build$VERSION.<clinit>(Build.java:229)
	at android.os.Build$VERSION.<clinit>(Build.java:21)
	at retrofit2.Platform.findPlatform(Platform.java:43)
```

I'm not sure why that class is available in studio but seems like detecting android platform based on the existence of that class is no more appropriate. 


Issue comments:
Also, seems like this error surfaced before but I was not seeing it until 4.1.
https://github.com/Microsoft/azure-tools-for-java/issues/363
😬 

Presumably this is for layoutlib support? Sucks that it's not isolated into a classloader.

Related: #2102.
bug on studio:
https://issuetracker.google.com/issues/156312959

This also seems to effect okhttp :( If there is some workaround, I would appreciate but i couldn't find since it runs on class initialization.

Pull request review comments:

Patch that resolved the issue:
diff --git a/build.gradle b/build.gradle
index 847eb2adc5..ac2120773e 100644
--- a/build.gradle
+++ b/build.gradle
@@ -4,7 +4,7 @@ import org.gradle.internal.jvm.Jvm
 buildscript {
   ext.versions = [
       'kotlin': '1.3.50',
-      'okhttp': '3.14.7',
+      'okhttp': '3.14.9',
       'protobuf': '3.10.0',
       'jaxb': '2.3.1',
   ]


Test patch:
Repository: square/retrofit
Issue: Run non-Kotlin tests in JVM without Kotlin stdlib/coroutines

This is already needed for our limited Kotlin support, but as it grows having all codepaths covered in a VM where the types are not present will be important.

Refs #3702

Issue comments:

Pull request review comments:
Our version of Kotlin is old enough that the stdlib isn't added by default. This is a hedge against future upgrades.

Patch that resolved the issue:
diff --git a/retrofit/build.gradle b/retrofit/build.gradle
index 83acc0c330..8d425cf80a 100644
--- a/retrofit/build.gradle
+++ b/retrofit/build.gradle
@@ -17,8 +17,6 @@ dependencies {
   testImplementation libs.assertj
   testImplementation libs.guava
   testImplementation libs.mockwebserver
-  testImplementation libs.kotlinStdLib
-  testImplementation libs.kotlinCoroutines
 }
 
 jar {
diff --git a/retrofit/gradle.properties b/retrofit/gradle.properties
index 774fe0fe97..f018996fb2 100644
--- a/retrofit/gradle.properties
+++ b/retrofit/gradle.properties
@@ -1,3 +1,5 @@
 POM_ARTIFACT_ID=retrofit
 POM_NAME=Retrofit
 POM_DESCRIPTION=A type-safe HTTP client for Android and Java.
+
+kotlin.stdlib.default.dependency=false
diff --git a/settings.gradle b/settings.gradle
index f9c04c9998..efd5ab00ee 100644
--- a/settings.gradle
+++ b/settings.gradle
@@ -2,6 +2,7 @@ rootProject.name = 'retrofit-root'
 
 include ':retrofit'
 include ':retrofit:android-test'
+include ':retrofit:kotlin-test'
 include ':retrofit:robovm-test'
 include ':retrofit:test-helpers'
 


Test patch:
diff --git a/retrofit/kotlin-test/build.gradle b/retrofit/kotlin-test/build.gradle
new file mode 100644
index 0000000000..b39ed4e17c
--- /dev/null
+++ b/retrofit/kotlin-test/build.gradle
@@ -0,0 +1,11 @@
+apply plugin: 'org.jetbrains.kotlin.jvm'
+
+dependencies {
+  testImplementation projects.retrofit
+  testImplementation projects.retrofit.testHelpers
+  testImplementation libs.junit
+  testImplementation libs.assertj
+  testImplementation libs.mockwebserver
+  testImplementation libs.kotlinStdLib
+  testImplementation libs.kotlinCoroutines
+}
diff --git a/retrofit/src/test/java/retrofit2/KotlinUnitTest.java b/retrofit/kotlin-test/src/test/java/retrofit2/KotlinUnitTest.java
similarity index 89%
rename from retrofit/src/test/java/retrofit2/KotlinUnitTest.java
rename to retrofit/kotlin-test/src/test/java/retrofit2/KotlinUnitTest.java
index 74216fe867..389441b166 100644
--- a/retrofit/src/test/java/retrofit2/KotlinUnitTest.java
+++ b/retrofit/kotlin-test/src/test/java/retrofit2/KotlinUnitTest.java
@@ -21,7 +21,6 @@
 import kotlin.Unit;
 import okhttp3.mockwebserver.MockResponse;
 import okhttp3.mockwebserver.MockWebServer;
-import org.junit.Ignore;
 import org.junit.Rule;
 import org.junit.Test;
 import retrofit2.http.GET;
@@ -45,8 +44,4 @@ public void unitOnClasspath() throws IOException {
     assertThat(response.isSuccessful()).isTrue();
     assertThat(response.body()).isSameAs(Unit.INSTANCE);
   }
-
-  @Ignore("This is implicitly tested by integration tests of the adapters and converters")
-  @Test
-  public void unitMissingFromClasspath() {}
 }
Repository: square/retrofit
Issue: Gson library has new version
Labels: PR welcome

 Google has released an update regarding the gson library showing integers sometimes as decimals. I request this update to be imported

Issue comments:
You should never depend on Retrofit to provide a version of a library. Declare a sibling dependency on Gson with the version you desire and your build system will ensure the newer of the two is used. We also never make Retrofit releases simply to expose updated versions of our transitive dependencies.

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 350e2932c4..e20fbdbb37 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -48,7 +48,7 @@ rxjava2 = { module = "io.reactivex.rxjava2:rxjava", version = "2.2.21" }
 rxjava3 = { module = "io.reactivex.rxjava3:rxjava", version = "3.1.1" }
 reactiveStreams = { module = "org.reactivestreams:reactive-streams", version = "1.0.3" }
 scalaLibrary = { module = "org.scala-lang:scala-library", version = "2.13.6" }
-gson = { module = "com.google.code.gson:gson", version = "2.8.9" }
+gson = { module = "com.google.code.gson:gson", version = "2.9.0" }
 jacksonDatabind = { module = "com.fasterxml.jackson.core:jackson-databind", version = "2.12.4" }
 jaxbApi = { module = "javax.xml.bind:jaxb-api", version.ref = "jaxb" }
 jaxbImpl = { module = "org.glassfish.jaxb:jaxb-runtime", version.ref = "jaxb" }


Test patch:
Repository: square/retrofit
Issue:  service eager validation is failed when using jacoco 

What kind of issue is this?
 - [x] Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests
       get fixed. Here’s an example: https://gist.github.com/swankjesse/6608b4713ad80988cdc9

Jacoco is a world famous code coverage tool  . And it add $jacocoInit() method to interface in order to finish their job. 
But it could cause Retrofit failed in eager service validation. 
Should Retrofit eager validation ignore SYNTHETIC method in such scene ?


```
public final class Retrofit {
 private void validateServiceInterface(Class<?> service) {
............
    if (validateEagerly) {
      Platform platform = Platform.get();
      for (Method method : service.getDeclaredMethods()) {
        if (!platform.isDefaultMethod(method) && !Modifier.isStatic(method.getModifiers())) {
          loadServiceMethod(method);
        }
      }
    }
  ...........
}
```

Issue comments:

Pull request review comments:
```suggestion
        if (!platform.isDefaultMethod(method)
            && !Modifier.isStatic(method.getModifiers())
            && !method.isSynthetic()) {
```

Patch that resolved the issue:
diff --git a/retrofit/src/main/java/retrofit2/Retrofit.java b/retrofit/src/main/java/retrofit2/Retrofit.java
index c5aa7dfb51..3390378db2 100644
--- a/retrofit/src/main/java/retrofit2/Retrofit.java
+++ b/retrofit/src/main/java/retrofit2/Retrofit.java
@@ -191,7 +191,9 @@ private void validateServiceInterface(Class<?> service) {
     if (validateEagerly) {
       Platform platform = Platform.get();
       for (Method method : service.getDeclaredMethods()) {
-        if (!platform.isDefaultMethod(method) && !Modifier.isStatic(method.getModifiers())) {
+        if (!platform.isDefaultMethod(method)
+            && !Modifier.isStatic(method.getModifiers())
+            && !method.isSynthetic()) {
           loadServiceMethod(service, method);
         }
       }


Test patch:
Repository: pinpoint-apm/pinpoint
Issue: Starting hbase in Quickstart fails if there is an older version of hbase already available
Labels: bug

Quickstart's start script does not properly unlink `hbase` under `pinpoint/quickstart/hbase/`.
Thus, the `ln` command creates a new link under the directory previously linked by `hbase`.

This issue should only manifest itself under *nix/osx systems as Windows users would set the path to hbase manually.


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/quickstart/bin/start-hbase.sh b/quickstart/bin/start-hbase.sh
index 299effd02b07..c5d33b2f1cc6 100755
--- a/quickstart/bin/start-hbase.sh
+++ b/quickstart/bin/start-hbase.sh
@@ -27,6 +27,7 @@ BASE_DIR=`dirname "$bin"`
 
 CONF_DIR=$BASE_DIR/conf
 HBASE_DIR=$BASE_DIR/hbase
+DATA_DIR=$BASE_DIR/data
 
 function func_check_hbase_installation
 {
@@ -58,6 +59,13 @@ function func_download_hbase
     fi
 }
 
+function delete_data_directory
+{
+    if [ -d $DATA_DIR ]; then
+        rm -r $DATA_DIR
+    fi
+}
+
 function func_install_hbase
 {
     if [ ! -d $HBASE_DIR ]; then
@@ -71,8 +79,12 @@ function func_install_hbase
         echo "Exiting"
         exit 0
     fi
+    delete_data_directory
     tar xzf $HBASE_FILE
     rm $HBASE_FILE
+    if [ -h hbase ]; then
+        unlink hbase
+    fi
     ln -s $HBASE_VERSION hbase
     cp $CONF_DIR/hbase/hbase-site.xml $HBASE_DIR/$HBASE_VERSION/conf/
     chmod +x $HBASE_DIR/$HBASE_VERSION/bin/start-hbase.sh
@@ -92,4 +104,4 @@ function func_start_hbase
     cd $CURRENT_DIR
 }
 
-func_start_hbase
\ No newline at end of file
+func_start_hbase


Test patch:
Repository: pinpoint-apm/pinpoint
Issue: [Collector] refactoring udp collector
Labels: enhancement

- UDPReceiver
- extract L4CheckFilter, NetworkAvailabilityCheckPacketFilter


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/collector/src/main/java/com/navercorp/pinpoint/collector/receiver/udp/PooledPacketWrap.java b/collector/src/main/java/com/navercorp/pinpoint/collector/receiver/udp/PooledPacketWrap.java
index 2bcbc36e0cd9..57afcead1ff6 100644
--- a/collector/src/main/java/com/navercorp/pinpoint/collector/receiver/udp/PooledPacketWrap.java
+++ b/collector/src/main/java/com/navercorp/pinpoint/collector/receiver/udp/PooledPacketWrap.java
@@ -43,7 +43,7 @@ public void run() {
         final DatagramPacket packet = pooledObject.getObject();
         try {
             packetHandler.receive(packet);
-        } catch (Exception e) {
+        } finally {
             pooledObject.returnObject();
         }
     }


Test patch:
Repository: pinpoint-apm/pinpoint
Issue: Handle cases where collected cpu load is NaN
Labels: bug

There was a case where calling `OperatingSystemMXBean.getSystemCpuLoad()` returned Double.NaN (the agent was ran on a virtual machine).

The data collected was as follows:

```
TAgentStatBatch(agentId:test-agent, startTimestamp:1441085794300, agentStats:[
    TAgentStat(timestamp:1441087205292, cpuLoad:TCpuLoad(systemCpuLoad:0.026276276276276277, jvmCpuLoad:5.983020928131048E-4), gc:TJvmGc(...)), 
    TAgentStat(timestamp:1441087802597, cpuLoad:TCpuLoad(systemCpuLoad:0.13733025877530106, jvmCpuLoad:9.909711377187762E-6), gc:TJvmGc(...)), 
    TAgentStat(timestamp:1441087802597, cpuLoad:TCpuLoad(systemCpuLoad:NaN, jvmCpuLoad:0.14527027027027026), gc:TJvmGc(...)), 
    TAgentStat(timestamp:1441087802597, cpuLoad:TCpuLoad(systemCpuLoad:NaN, jvmCpuLoad:0.1275), gc:TJvmGc(...)), 
    TAgentStat(timestamp:1441087802597, cpuLoad:TCpuLoad(systemCpuLoad:NaNjvmCpuLoad:0.125), gc:TJvmGc(...)), 
    TAgentStat(timestamp:1441087802597, cpuLoad:TCpuLoad(systemCpuLoad:0.0jvmCpuLoad:0.125), gc:TJvmGc(...))
])
```

Need a NaN check - use `Double.isNaN()`.
(equals check does not work on NaNs as `Double.NaN != Double.NaN`)


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/profiler/src/main/java/com/navercorp/pinpoint/profiler/monitor/codahale/cpu/CpuLoadCollector.java b/profiler/src/main/java/com/navercorp/pinpoint/profiler/monitor/codahale/cpu/CpuLoadCollector.java
index 3b47af433e2a..547864abe179 100644
--- a/profiler/src/main/java/com/navercorp/pinpoint/profiler/monitor/codahale/cpu/CpuLoadCollector.java
+++ b/profiler/src/main/java/com/navercorp/pinpoint/profiler/monitor/codahale/cpu/CpuLoadCollector.java
@@ -61,6 +61,6 @@ public TCpuLoad collectCpuLoad() {
     }
 
     private boolean notCollected(double cpuLoad) {
-        return cpuLoad < 0;
+        return cpuLoad < 0 || Double.isNaN(cpuLoad);
     }
 }


Test patch: