[jira] Commented: (WICKET-3136) JVM 1.6 crash caused by WicketObjectOutputStream, ClassStreamHandler, and Page.writePageObject

["Johan Compagner (JIRA)" <ji...@apache.org>]

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

Johan Compagner commented on WICKET-3136:
-----------------------------------------

my vote is more to remove WicketObject in and output streams
We tried it to optimize it. But the problem is that all kinds of hacks and hooks and special threat meant are in the core of java for this
So that we will be constantly updating and fixing problems for specific releases (and that is some times hard because of compile dependencies...)

I think if we need some kind of special wicket serialization we should not use object output stream but have our own completely stand alone implementation (how does terracotta do it?)

> JVM 1.6 crash caused by WicketObjectOutputStream, ClassStreamHandler, and Page.writePageObject 
> -----------------------------------------------------------------------------------------------
>
>                 Key: WICKET-3136
>                 URL: https://issues.apache.org/jira/browse/WICKET-3136
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.4.12
>         Environment: JVM 1.6.0_22, CentOS release 5.3 (Final) and Mac OS 10.6.4
>            Reporter: Roland Groen
>            Assignee: Johan Compagner
>             Fix For: 1.4.14, 1.5-M4
>
>         Attachments: fix-test-WICKET-3136.patch, hs_err_pid3145.log, test-WICKET-3136.patch
>
>
> The JVM 6u22 (1.6.0_22) crashes while clicking on a page in the wicket application. This is always the same page, but there are pages that function. When serializing a Page object with the pageMapName field set, a JVM 1.6 crashes on a segmentation fault. The error message is:
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0xf44a859e, pid=3145, tid=2969234320
> #
> # JRE version: 6.0_22-b04
> # Java VM: Java HotSpot(TM) Server VM (17.1-b03 mixed mode linux-x86 )
> # Problematic frame:
> # J  org.apache.wicket.util.io.WicketObjectOutputStream$HandleTable.hash(Ljava/lang/Object;)I
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> What goes on (and it took some time to find it):
> The WicketObjectOutputStream has a field wich is called classHandler. This classHandler is suppose to match the class of the curObject. 
> When Page.writePageObject is called AND the field Page.pageMapName is set, the method Page.writePageObject  will call writeObject(pageMapName). This call will change the value of WicketObjectOutputStream.classHandler into the classHandler of java.lang.String somewhere in WicketObjectOutputStream.writeObjectOverride. What happens next is a true disaster. Though some abstractions (PageSerializer), the method WicketObjectOutputStream.defaultWriteObject will is called. This method states:
> classHandler.writeFields(this, curObject);
> and due to fact that classHandler is a class handler of java.lang.String and not the one of the curObject, an instance of FieldAndIndex belonging to String.value  will be called with another object. This ends up at calling unsafe.getObject(object, index) (a native method) with the wrong object reference, something which is not a good idea with sun.misc.Unsafe. Every operation on the returned object will crash the JVM. Unfortunately the next in line to operate on the object is WicketObjectOutputStream.HandleTable.hash which also calls a native method called System.identityHashCode. This method is known for some JVM crashes, and has been attributed for the JVM crash for a while during the investigation into this JVM crash.
> The solutions:
> 1) Do not use the WicketObjectOutputStream/WicketObjectStreamFactory. Works.
> 2) The method org.apache.wicket.Page.writePageObject(ObjectOutputStream) should not do a s.writeObject(pageMapName), but a s.writeUTF(pageMapName) instead. This way, the WicketObjectOutputStream.classHandler will not get the wrong value. org.apache.wicket.Page.readPageObject(ObjectInputStream) should be matched, of course.
> 3) WicketObjectOutputStream.defaultWriteObject() should update/get the right classHandler reference, just as WicketObjectOutputStream.writeObjectOverride(Object) does. You might even consider dropping the field entirely. 
> The last option seems the best to me, because calling a writeObject from writePageObject is not semantically incorrect, furthermore, there might be other instances of this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.