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.ch...@oracle.com <mailto:mandy.ch...@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



Reply via email to