RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Daniel Fuchs
daniel.fuchs at oracle.com
Tue Oct 1 07:54:53 PDT 2013
On 10/1/13 4:50 PM, Seán Coffey wrote:
>
> On 01/10/2013 14:51, Daniel Fuchs wrote:
>> On 10/1/13 3:09 PM, Seán Coffey wrote:
>>> Since I'm only creating a dummy socketImpl to test the
>>> classcastexception, no real networking stack is in place here. I'm
>>> catching the NPE that would be thrown from the native
>>> Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the
>>> underlying socket passed to it is null.
>>>
>>> C:\tmp>java CustomSocketImplFactory
>>> Created Socket[addr=null,port=0,localport=0]
>>> Exception in thread "main" java.lang.NullPointerException: socket is
>>> null
>>> at java.net.TwoStacksPlainSocketImpl.socketAccept(Native
>>> Method)
>>
>> That's what I would have expected from your previous changeset.
>>
>> But you're no longer passing null - right? Now you're passing
>> an instance of CustomSocketImpl.
>>
>> So where does the NPE come from? Could it be because you should
>> be calling:
>> ServerSocket.setSocketImplFactory(new CustomSocketImplFactory());
>> and not:
>> Socket.setSocketImplFactory(new CustomSocketImplFactory()); ?
> The original bug stemmed from a custom socket Impl interacting with the
> JDK ServerSocket Impl. If I move both Socket and ServerSocket factory
> implementations over to use the custom Impl, the testcase doesn't get to
> walk through the JDK serverSocket code and the ClassCastException is not
> seen.
>
> The NPE seen is coming from down in the native stack when the JDK
> ServerSocket is running through accept request (from our client socket).
> I don't think it's an issue for this case.
>
> line 611 :
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/src/windows/native/java/net/TwoStacksPlainSocketImpl.c
>
>
> regards,
> Sean.
Thanks Seán. You convinced me.
-- daniel
>> Or should you call both?
>>
>> best regards,
>>
>> -- daniel
>>
>>
>>>
>>> Regards,
>>> Sean.
>>>
>>>>
>>>> Or is that going to hide future bugs?
>>>>
>>>> best regards
>>>>
>>>> -- daniel (not a reviewer)
>>>
>>
>
More information about the net-dev
mailing list