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