GC closes my ServerSocket

[Weijun Wang]

Updated:

   http://cr.openjdk.java.net/~weijun/7176574/webrev.01/

Thanks
Max

On 06/13/2012 05:52 PM, Chris Hegarty wrote:
>
>
> On 13/06/2012 10:23, Weijun Wang wrote:
>> Please anyone take a review:
>>
>> http://cr.openjdk.java.net/~weijun/7176574/webrev.00/
>>
>> By assigning to a local variable hopefully it stays alive on the stack
>> during the whole method.
>
> If they don't then we have a real problem ;-)
>
>> Noreg-self.
>>
>> *Chris*: I didn't indented the whole test by wrapping them into a
>> try-finally (or try-with-resources) block. The test runs in othervm and
>> I guess the sockets will be closed anyway.
>
> Strictly speaking, after the construction of these ServerSocket instance
> you should wrap the remainder of the code in a try finally to ensure
> that close is called. Even with othervm mode when the vm is exiting
> there is not guarantee that finalizers are run.
>
> I think it would be best to add a finally block here to reduce the
> chances of strange/intermittent behavior as a result of running this
> test. Either the test itself or excessive resource hogging on the
> system. But if you are really against it, I can live with what you have ;-)
>
> -Chris.
>
>>
>> Thanks
>> Max
>>
>> On 06/13/2012 05:08 PM, Chris Hegarty wrote:
>>>
>>>
>>> On 13/06/2012 09:51, Alan Bateman wrote:
>>>> On 13/06/2012 09:38, Weijun Wang wrote:
>>>>> Hi All
>>>>>
>>>>> I have a test that basically looks like:
>>>>>
>>>>> int p = new ServerSocket(0).getLocalPort();
>>>>> //....
>>>>> new Socket("localhost", p);
>>>>>
>>>>> Recently it's failing on solaris-i586, and after some investigation, I
>>>>> realize that the ServerSocket object is GC'ed and auto-closed.
>>>>>
>>>>> (But why only recently?)
>>>>>
>>>>> So I change the first line to
>>>>>
>>>>> ServerSocket ss = new ServerSocket(0);
>>>>> int p = ss.getLocalPort();
>>>>>
>>>>> and it's running fine.
>>>>>
>>>>> I want to know if the ServerSocket object still has a chance to be
>>>>> closed. If yes, I'll add a
>>>>>
>>>>> ss.close();
>>>>>
>>>>> at the end to be safer.
>>>>>
>>>>> Thanks
>>>>> Max
>>>> HotSpot changes I assume, perhaps changes to the reference
>>>> processing or
>>>> default heap settings.
>>>
>>> Right, I assume there was some VM change that started this test to fail
>>> recently, but clearly this is a test issue. It was just passing all this
>>> time by accident, and there is an inherent race between the test and the
>>> GC/finalizer thread.
>>>
>>> You should fix the test as you suggested. Also close the serversocket in
>>> a finally block ( or equivalent ). You should not rely on the finalizer
>>> to close it out.
>>>
>>> -Chris.
>>>
>>>>
>>>> -Alan