Probable bug within sun.management.StackTraceElementCompositeData

[Sven Reimers]

Hi Mandy,

Thanks for the pointer. I have not yet investigated the usage, but will
check if we can use the official API instead.

Thanks again for the quick response.

-Sven

Mandy Chung <mandy.chung at oracle.com> schrieb am Mi., 17. Okt. 2018, 19:50:

> Hi Sven,
>
> This NetBeans SamplesOutputStream calls
> sun.management.ThreadInfoCompositeData.toCompositeData
> which is an internal API.  It will be inaccessible when
> strong encapsulation is enabled.
>
> Have you looked into javax.management API to get the
> CompositeData directly?
>
> Mandy
>
> On 10/15/18 10:51 AM, Mandy Chung wrote:
>
> Hi Sven,
>
> It's indeed a bug in the order of names and values when constructing
> CompositeData for StackTraceElement.  I created
> https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue.
>
> Mandy
>
> On 10/14/18 3:52 PM, David Holmes wrote:
>
> Hi Sven,
>
> Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
>
> Thanks,
> David
>
> On 15/10/2018 5:42 AM, Sven Reimers wrote:
>
> Hi all,
>
> I hope this is the correct e-mailing list. During out testing of Apache
> NetBeans 10 we discovered a problem with self sampling capability of
> NetBeans. Digging further into this problem (NETBEANS-1359
> <https://issues.apache.org/jira/browse/NETBEANS-1359>
> <https://issues.apache.org/jira/browse/NETBEANS-1359>) I debugged through
> the code and it seems that there is a problem with the order of the values
> and the order of the attributes.
>
>  From the code I see the order of the values is
>
>          final Object[] stackTraceElementItemValues = {
>              ste.getClassLoaderName(),
>              ste.getModuleName(),
>              ste.getModuleVersion(),
>              ste.getClassName(),
>              ste.getMethodName(),
>              ste.getFileName(),
>              ste.getLineNumber(),
>              ste.isNativeMethod(),
>          };
>
> compared to  the order of the attributes
>
>
>      private static final String[] V5_ATTRIBUTES = {
>          CLASS_NAME,
>          METHOD_NAME,
>          FILE_NAME,
>          LINE_NUMBER,
>          NATIVE_METHOD,
>      };
>
>      private static final String[] V9_ATTRIBUTES = {
>          CLASS_LOADER_NAME,
>          MODULE_NAME,
>          MODULE_VERSION,
>      };
>
>      private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES =
>          Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream)
>                .toArray(String[]::new);
>
> which can be expanded to
>
>          CLASS_NAME,
>          METHOD_NAME,
>          FILE_NAME,
>          LINE_NUMBER,
>          NATIVE_METHOD,
>          CLASS_LOADER_NAME,
>          MODULE_NAME,
>          MODULE_VERSION,
>
> With the difference in ordering you will get an exception  in
> CompositeDataSupport, if you try to convert things (lines 228ff)
>
>          // Check each value, if not null, is of the open type defined for
> the
>          // corresponding item
>          for (String name : namesFromType) {
>              Object value = items.get(name);
>              if (value != null) {
>                  OpenType<?> itemType = compositeType.getType(name);
>                  if (!itemType.isValue(value)) {
>                      throw new OpenDataException(
>                              "Argument value of wrong type for item " +
> name
> +
>                              ": value " + value + ", type " + itemType);
>                  }
>              }
>          }
>
> which is hard to compensate from the caller side.
>
> I think the change, which introduced this was
>
>
> https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470
>
> The proposed patch seems simple, just change the ordering of the
> attributes
>
>    private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES =
>          Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream)
>                .toArray(String[]::new);
>
> or change the value ordering to fit the attributes order.
>
> Can anyone confirm the analysis?
>
> Thanks
>
> -Sven
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181017/6f1e2960/attachment.html>