[security-dev 00011]: Re: BUG: krb5 client leaks UDP, causes failure under load.
Seema Malkani
Seema.Malkani at Sun.COM
Wed Aug 1 22:14:40 UTC 2007
Thanks for reporting this issue.
Apologies, don't know the details of how this report was missed. Sun
bug-id 6588160 has been created from the webbug that you submitted.
If you want us to evaluate your patch, please read following webpage on
"how to contribute to the OpenJDK project" and sign the required agreement.
http://openjdk.java.net/contribute/
Seema
Jan Grant wrote:
> I've tried to raise this in the past; the opening of the relevant bits
> of the JDK have encouraged me to try again.
>
> sun.security.krb5.internal.UDPClient has no close() method; and the
> UDPClient-using code path in sun.security.krb5.KrbKdcReq (which has a
> few other close-to-the-coalface errors) consequently leaks FDs (unlike
> the TCP path, which has a try/finally that closes the socket properly).
>
> We're seeing a krb5 client application (the Yale CAS SSO) keel over in
> no time due to FD exhaustion. A trivial fix (the non-whitespace part of
> the diff is 8 lines) sorts this out.
>
>
> I've tried to report this in the past without much luck: engineers were
> initially very responsive then it got picked up and kind of fell flat.
> Whilst I'm chasing the beauracracy here to get a release signed, I think
> the patch itself is so trivial it probably doesn't warrant much concern.
>
> Full report is stashed here:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=110912&cat=java
>
> including a patch against the contents of jdk_sec-1_5_0-src-scsl.zip;
> this affects all platforms.
>
> A unit test is hard to do; however if you look at support case 37763365
> you should find a small piece of code (and associated typescipt) that
> demonstrates the krb5 client slowly using up UDP sockets.
>
> Eventually the GC will kick in and reclaim these; however, (1) relying
> on GC to manage any resource other than memory is a bug; (2) we're still
> seeing failures before GC has a chance to work.
>
> Let me know what I can do to progress this; according to various reports
> this fault has been around for a long time. It'd be good to knock it on
> the head.
>
> Cheers,
> jan
>
>
More information about the security-dev
mailing list