JDK-8047221 : NPE in com.sun.corba.se.impl.io.OutputStreamHook$HookPutFields.put
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:rmi-iiop
  • Affected Version: 7u55
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-06-18
  • Updated: 2014-07-23
  • Resolved: 2014-07-02
Related Reports
Duplicate :  
Description
Cu seeing NPE since the InetAddress changes in 7u21 

We found one more issue with JRE 7u55/7u45 when a remote call took InetAddress as a variable, 
Exception in thread "Thread-183" java.lang.NullPointerException 
       at java.util.Hashtable.put(Hashtable.java:514) 
       at com.sun.corba.se.impl.io.OutputStreamHook$HookPutFields.put(OutputStreamHook.java:115) 
       at java.net.InetAddress.writeObject(InetAddress.java:1600) 
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
       at java.lang.reflect.Method.invoke(Method.java:606) 
       at com.sun.corba.se.impl.io.IIOPOutputStream.invokeObjectWriter(IIOPOutputStream.java:620) 
       at com.sun.corba.se.impl.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:586) 
       at com.sun.corba.se.impl.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:174) 
       at com.sun.corba.se.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:236) 
       at com.sun.corba.se.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:218) 
       at com.sun.corba.se.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:150) 
       at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.writeRMIIIOPValueType(CDROutputStream_1_0.java:807) 
       at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:856) 
       at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:870) 
       at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:665) 
       at com.sun.corba.se.impl.encoding.CDROutputStream.write_value(CDROutputStream.java:250) 
Comments
Duplicate of JDK-7095856
02-07-2014

It's always been possible to create InetAddress instances with a null hostname. eg InetAddress a = InetAddress.getByAddress(null, new byte[] {1,2,3,4});
19-06-2014

OK, then a null value is acceptable for a serialized InetAddress, even though getHostName() will never return a null (as per API). using HasMap is the solution then, and we expect that only a single thread will be invoking this code for any serialization call flow taking place for an RMI-IIIOP call.
19-06-2014

I suspect that the hostname field always had a null value ( which is acceptable ).
19-06-2014

Just to confirm: The difference here is the fact that there is a writeObject method in InetAddress, and this triggers the cobra/rmi-iiop code to take a code path that it previous did not, right? The null value just happens to be the point where it fails. Couldn't this happen for any other object, that also has a writeObject method, and a null value, not just InetAddress? InetAddress is not immutable. The Inet6Address test issue you refer to, JDK-8042902?? , I think is actually a test issue. Any code dealing with serialized InetAddress objects needs to be able to handle null values. If only to protect itself against bad/malicious streams.
19-06-2014

prior to the restructuring of the InetAddress, there wasn't any writeObject method. With the introduction of this method, the RMI-IIOP serialization processing is now using an IIOPOutputSteam ( is_a OutputStreamHook) and various other OutputStreams through level of indirection and delegation. It was found with a Inet6Adress serialization test that there is potential for some spurious behaviour when the hostname of InetAddress is not set. As such, the InetAddress when serialized in an RMI-IIOP call wouldn't have gone though the OutputStreamHook, and this issue highlights an internal representational deficiency in the associated PutField. At fundamental level is the InetAddress, the encapsulation of an IP address or the encapsulation of an IP address together with the mapped hostname? If its the latter then serialization of InetAddress with non null hostnames would make sense
18-06-2014

I need to check what is in the serial stream for an InetAddress instance, with a null hostname, pre 7u21, but it is certainly acceptable for the serial stream to contain a null value for a reference type. That said, I accept that this may have changed because of the InetAddress serialization changes.
18-06-2014

This appears to be a duplicate of JDK-7095856 which needs to be fixed. The alternative would be to take an approach similar to JDK-7038843 and change the InetAddress writeObject code to not use the PutFields mechanism.
18-06-2014