Probable JDK6 regression: SSLSocketImpl leak

[Nathan Bryant]

Hi,

I did do a little poking with MAT/VisualVM. I will try again


On Fri, Mar 21, 2014 at 11:43 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:

> Hi Nathan,
>
>
> On 21.3.2014 16:37, Nathan Bryant wrote:
>
>> Hi,
>>
>> Looking for some advice on how to debug an issue that's hitting our
>> production stack.
>>
>> We have a grails app that's using apache httpclient 4.3.3 for transport to
>> our backend tier over SSL. This worked fine for a long time but started to
>> leak after our latest push.
>>
>> Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
>> associated byte[] and SocksSocketImpl) that can not be reclaimed. Clicking
>> through everything in jmap, I can not find a path to the rootset (the
>> paths
>> to rootset query times out). There are references from finalizers, but I
>> am
>>
>
> Would it be possible to use more production-ready tools to analyze the
> heap? Like MAT or VisualVM? You should be able to get more meaningful
> information out of them.
>
> Cheers,
>
> -JB-
>
>
>  consistently seeing "Number of objects pending for finalization: 0" via
>> jhat and via jmap -finalizerinfo and other heap analysis tools. Thus,
>> these
>> are objects that "should" be reclaimed by GC.
>>
>> The finalizer thread itself appears to be idle:
>>
>> "Finalizer" daemon prio=10 tid=0x0000000001dcc000 nid=0x2437 in
>>
>>> Object.wait() [0x00007f3b8f5f4000]
>>>     java.lang.Thread.State: WAITING (on object monitor)
>>> at java.lang.Object.wait(Native Method)
>>> - waiting on <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
>>> - locked <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
>>> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
>>>
>>
>>
>> The app works on:
>>
>> $ java -version
>>
>>> java version "1.6.0_27"
>>> OpenJDK Runtime Environment (IcedTea6 1.12.6)
>>> (6b27-1.12.6-1ubuntu0.10.04.4)
>>> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
>>>
>>>
>>
>> But fails on:
>>
>>
>> $ java -version
>>
>>> java version "1.6.0_30"
>>> OpenJDK Runtime Environment (IcedTea6 1.13.1)
>>> (6b30-1.13.1-1ubuntu2~0.12.04.1)
>>> OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
>>>
>>
>>
>> It also fails on the client/32-bit version of 1.6.0_30.
>>
>> If these objects are pinned by references from native code, I am
>> assuming this doesn't show up in the heap dump?
>>
>>
>