Probable JDK6 regression: SSLSocketImpl leak

Nathan Bryant nathan.bryant at plusgrade.com
Fri Mar 21 18:13:38 UTC 2014


Thanks, Andrew.


On Fri, Mar 21, 2014 at 12:31 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/21/2014 03:37 PM, Nathan Bryant wrote:
>
> > 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
> > 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.
>
> We know what this is.  It was fixed by this patch:
>
>
> # HG changeset patch
> # User aph
> # Date 1393513709 0
> # Node ID 04e4c3ec6516727f01f91a9ce8cb72586a3bc502
> # Parent  942d4ba93be74b1c401d6532f116da80f5466303
> OPENJDK6-29: JDK fails to zero jdk_version_info correctly
> Reviewed-by: andrew
>
> diff -r 942d4ba93be7 -r 04e4c3ec6516 src/share/native/common/jdk_util.c
> --- a/src/share/native/common/jdk_util.c        Wed Feb 26 18:06:02 2014
> +0000
> +++ b/src/share/native/common/jdk_util.c        Thu Feb 27 15:08:29 2014
> +0000
> @@ -76,7 +76,7 @@
>      }
>
>
> -    memset(info, 0, sizeof(info_size));
> +    memset(info, 0, info_size);
>      info->jdk_version = ((jdk_major_version & 0xFF) << 24) |
>                          ((jdk_minor_version & 0xFF) << 16) |
>                          ((jdk_micro_version & 0xFF) << 8)  |
>
>
> Andrew.
>
>



More information about the discuss mailing list