Probable bug within sun.management.StackTraceElementCompositeData

Mandy Chung mandy.chung at oracle.com
Wed Oct 17 16:26:22 UTC 2018


I plan to request the backport to 11u.

Mandy

On 10/16/18 11:16 PM, Sven Reimers wrote:
> Hi,
>
> thanks for fixing. What about a backport to 11?
>
> Thanks
>
> -Sven
>
>
>
> Mandy Chung <mandy.chung at oracle.com <mailto:mandy.chung at oracle.com>> 
> schrieb am Mo., 15. Okt. 2018, 19:50:
>
>     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/84b0588a/attachment-0001.html>


More information about the serviceability-dev mailing list