You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2018/05/26 12:47:00 UTC

[jira] [Commented] (WICKET-6531) Crash in Unsafe.getObject when running on the J9 VM

    [ https://issues.apache.org/jira/browse/WICKET-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491643#comment-16491643 ] 

Martin Grigorov commented on WICKET-6531:
-----------------------------------------

I'd recommend to *not* use CheckingObjectOutputStream in non-Oracle JVMs.
This class is for debugging purposes and it indeed uses internals to do its job.
org.apache.wicket.serialize.java.JavaSerializer#newObjectOutputStream() should return a plain java.io.ObjectOutputStream.

We can use "java.vm.vendor" system property to check whether it should be enabled or not automatically in the static block (lines 234-269).

> Crash in Unsafe.getObject when running on the J9 VM
> ---------------------------------------------------
>
>                 Key: WICKET-6531
>                 URL: https://issues.apache.org/jira/browse/WICKET-6531
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 7.9.0, 8.0.0-M8
>         Environment: J9 VM (Java7) on AIX
>            Reporter: Kevin Langman
>            Priority: Major
>
> The CheckingObjectOutputStream class is using introspection of JVM internals to load object fields and array elements during serialization. This is a risky business given that there is no guarantee that all JVM implementations will implement the serialization internals in the same way. For the crash I am reporting here, we are checking an object that extends BigDecimal, but the J9 VM has its own implementation of BigDecimal and therefore has special handling of BigDecimal serialization so that it can (for compatibility reasons) mimic the byte-stream that would be produced by OpenJDK. This results in the CheckingObjectOutputStream code attempting to read fields out of an object that does not actually exist in the object, but only reflects the fields that will be written out to the serialization byte-stream.
>  
> In CheckingObjectOutputStream.checkFields() there is code to prevent checking objects that are instances of String, Number, Date, Boolean and Class. If this check was also done prior to checking array elements in internalCheck() then the the crash I am reporting here would not have occurred and therefore I am proposing that we add the following 'if statement' into the code:
>  
> CheckingObjectOutputStream.internalCheck() – Line 394:
> for (int i = 0; i < objs.length; i++)
> {
>    *if (objs[i] instanceof String || objs[i] instanceof Number  ||*
>          *objs[i] instanceof Date   || objs[i] instanceof Boolean ||*
>        *objs[i] instanceof Class)*
>    *{*
>       *// filter out common cases*
>    *}else{*
>       CharSequence arrayPos = new StringBuilder(4).append('[').append(i).append(']');
>       simpleName = arrayPos;
>       fieldDescription += arrayPos;
>       check(objs[i]);
>    *}*
> }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)