Probable bug within sun.management.StackTraceElementCompositeData

[Mandy Chung]

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>) 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/20181015/419673ab/attachment-0001.html>