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