Probable bug within sun.management.StackTraceElementCompositeData

[Sven Reimers]

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

-- 
Sven Reimers

* Senior Expert Software Architect
* Java Champion
* Apache NetBeans Committer
*
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009