java.lang.NullPointerException: Method name is null

JDK Bug System | Tomáš Hůrka | 2 years ago
  1. 0

    [JDK-8067662] "java.lang.NullPointerException: Method name is null" from StackTraceElement.<init> - Java Bug System

    java.net | 11 months ago
    java.lang.NullPointerException: Method name is null
  2. 0

    We see strange NPE when taking Thread-dump via JMX when doing CPU profiling in NetBeans Profiler and VisualVM. The NPE looks like this: java.lang.NullPointerException: Method name is null at java.util.Objects.requireNonNull(Objects.java:228) at java.lang.StackTraceElement.<init>(StackTraceElement.java:72) at sun.management.StackTraceElementCompositeData.from(StackTraceElementCompositeData.java:55) at sun.management.ThreadInfoCompositeData.stackTrace(ThreadInfoCompositeData.java:317) at java.lang.management.ThreadInfo.<init>(ThreadInfo.java:277) at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) and if I do thread dump of the same profiled application via Attach API, I see this: "Intro" #26 prio=1 os_prio=31 tid=0x00007f949bc10800 nid=0xe41f waiting on condition [0x000000012bec8000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at java2d.Intro$Surface.null (Redefined) at java.lang.Thread.null (Redefined) note the "null" at the place of the method name. This corresponds to the NPE from JMX. All this leads me to the JDK-8025238, which introduced the "null (Redefined)" in the stack trace. It looks like there are some changes in handling method_id of redefined methods, since the above problems are new in JDK 8. JDK 7u72 works fine. JDK-8025238, fixed the problem for stack trace taken via Attach API, but JMX code is broken - it does not count with the fact that method name can be null. There is one very interesing thing - if you take a heap dump in the situation, when JXM thread dump fails with NPE and thread dump taken via Attach API displays "Thread.null (Redefined)", the stack traces stored in the heap dump have correct method names. So there is a way to do it right without "null" names. As a proof of concept, I am attaching the patch against JDK8u-dev, which fixes NPE in JMX thread dump and also avoids "null" method names in Attach API thread dump. This patch does not use method_id returned by method->method_idnum(). It looks like conversion to method_id and back to Method* does not work correctly for old redefined methods, which are still on the stack. Note that attached patch does not solve similar problem in java_lang_Throwable::get_stack_trace_element(), which should also updated to use MethodHandle instead of method_id.

    JDK Bug System | 2 years ago | Tomáš Hůrka
    java.lang.NullPointerException: Method name is null
  3. 0

    We see strange NPE when taking Thread-dump via JMX when doing CPU profiling in NetBeans Profiler and VisualVM. The NPE looks like this: java.lang.NullPointerException: Method name is null at java.util.Objects.requireNonNull(Objects.java:228) at java.lang.StackTraceElement.<init>(StackTraceElement.java:72) at sun.management.StackTraceElementCompositeData.from(StackTraceElementCompositeData.java:55) at sun.management.ThreadInfoCompositeData.stackTrace(ThreadInfoCompositeData.java:317) at java.lang.management.ThreadInfo.<init>(ThreadInfo.java:277) at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) and if I do thread dump of the same profiled application via Attach API, I see this: "Intro" #26 prio=1 os_prio=31 tid=0x00007f949bc10800 nid=0xe41f waiting on condition [0x000000012bec8000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at java2d.Intro$Surface.null (Redefined) at java.lang.Thread.null (Redefined) note the "null" at the place of the method name. This corresponds to the NPE from JMX. All this leads me to the JDK-8025238, which introduced the "null (Redefined)" in the stack trace. It looks like there are some changes in handling method_id of redefined methods, since the above problems are new in JDK 8. JDK 7u72 works fine. JDK-8025238, fixed the problem for stack trace taken via Attach API, but JMX code is broken - it does not count with the fact that method name can be null. There is one very interesing thing - if you take a heap dump in the situation, when JXM thread dump fails with NPE and thread dump taken via Attach API displays "Thread.null (Redefined)", the stack traces stored in the heap dump have correct method names. So there is a way to do it right without "null" names. As a proof of concept, I am attaching the patch against JDK8u-dev, which fixes NPE in JMX thread dump and also avoids "null" method names in Attach API thread dump. This patch does not use method_id returned by method->method_idnum(). It looks like conversion to method_id and back to Method* does not work correctly for old redefined methods, which are still on the stack. Note that attached patch does not solve similar problem in java_lang_Throwable::get_stack_trace_element(), which should also updated to use MethodHandle instead of method_id.

    JDK Bug System | 2 years ago | Tomáš Hůrka
    java.lang.NullPointerException: Method name is null
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Bug ID: JDK-8067662 "java.lang.NullPointerException: Method name is null" from StackTraceElement.<init>

    java.com | 2 months ago
    java.lang.NullPointerException: Method name is null
  6. 0

    appengine NullPointerException: Method name is null on application startup

    Google Groups | 4 months ago | Luis Angel Cano via StackOverflow
    java.lang.NullPointerException: Method name is null

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.NullPointerException

      Method name is null

      at java.util.Objects.requireNonNull()
    2. Java RT
      ThreadInfo.from
      1. java.util.Objects.requireNonNull(Objects.java:228)
      2. java.lang.StackTraceElement.<init>(StackTraceElement.java:72)
      3. sun.management.StackTraceElementCompositeData.from(StackTraceElementCompositeData.java:55)
      4. sun.management.ThreadInfoCompositeData.stackTrace(ThreadInfoCompositeData.java:317)
      5. java.lang.management.ThreadInfo.<init>(ThreadInfo.java:277)
      6. java.lang.management.ThreadInfo.from(ThreadInfo.java:794)
      6 frames