Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8283784

java_lang_String::as_platform_dependent_str stores to oop in native state

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P4
    • 19
    • 17, 19
    • hotspot
    • b17

    Description

      In the loom repository I'm experimenting with stricter checks in the Access API to find places where we access oops while in the native or blocked state. Accessing oops in those states are dangerous, because a safepoint can be started and run simultaneously. Some code safeguards this by holding the thread lock, but in places were we don't we need to take a closer look and fix this.

      This bug is one that seems to be existing in the upstream repository:

      char* java_lang_String::as_platform_dependent_str(Handle java_string, TRAPS) {
        typedef char* (*to_platform_string_fn_t)(JNIEnv*, jstring, bool*);
        static to_platform_string_fn_t _to_platform_string_fn = NULL;

        if (_to_platform_string_fn == NULL) {
          void *lib_handle = os::native_java_library();
          _to_platform_string_fn = CAST_TO_FN_PTR(to_platform_string_fn_t, os::dll_lookup(lib_handle, "GetStringPlatformChars"));
          if (_to_platform_string_fn == NULL) {
            fatal("GetStringPlatformChars missing");
          }
        }

        char *native_platform_string;
        { JavaThread* thread = THREAD;
          jstring js = (jstring) JNIHandles::make_local(thread, java_string());
          bool is_copy;
          HandleMark hm(thread);
          ThreadToNativeFromVM ttn(thread);
          JNIEnv *env = thread->jni_environment();
          native_platform_string = (_to_platform_string_fn)(env, js, &is_copy);
          assert(is_copy == JNI_TRUE, "is_copy value changed");
          JNIHandles::destroy_local(js);
        }
        return native_platform_string;
      }

      The JNIHandles::destroy_local function calls NativeAccess<>::oop_store(jobject_ptr(handle), (oop)NULL), while inside the scope that has put the thread in the native state. It should probably be moved outside the ThreadToNativeFromVM scope.

      This was found with extra verification code in the Access API, while running com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java.

      Attachments

        Issue Links

          Activity

            People

              dholmes David Holmes
              stefank Stefan Karlsson
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: