hg: jdk8/tl/jdk: 7200277: [parfait] potential buffer overflow in npt/utf.c
Changeset: 94cc251d0c45 Author:sla Date: 2013-09-20 16:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94cc251d0c45 7200277: [parfait] potential buffer overflow in npt/utf.c Reviewed-by: dsamersoff, dcubed ! src/share/npt/utf.c
Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX
After a brief discussion with Chris, we decided to revert the position of the call to lookupIfLocalAddrs so as to give the local host primacy over DNS. Latest (and hopefully last) webrev here: http://cr.openjdk.java.net/~robm/7180557/webrev.03/ -Rob On 14/09/13 00:00, Rob McKenna wrote: Hi Bernd, I should have said in the context of this bug. What I meant was removing AI_CANONNAME doesn't resolve the issue as far as Mac is concerned. I.e. I still see the UnknownHostException. In this particular case the hostname is not set via the hosts file. In the latest webrev the call to getifaddrs only occurs if getaddrinfo fails. -Rob On 13/09/13 20:28, Bernd Eckenfels wrote: Am 13.09.2013, 19:32 Uhr, schrieb Rob McKenna : W.r.t. the use of AI_CANONNAME, this doesn't actually make a difference in the context of this fix, but is definitely something that should be looked at. I'll put it on the todo list. I think it does make a difference: If you remove the CANON flag getaddrinfo() will not do DNS lookups when the host is configured to prefer the hosts file (which it should do on Linux and OSX). And so the platform specific lookupIfLocalhost() can be put after the getaddrinfo() (again). I actually think the bug "exists" on all platforms. If getaddrinfo() fails because neighter hosts nor DNS file finds the name this can happen on all platforms. I dont think it helps to add a fallback only on MACOSX (and there is certainly no need to prefer the fallback then). Gruss Bernd
Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX
Looks fine to me Rob, thanks. -Chris. On 09/20/2013 03:58 PM, Rob McKenna wrote: After a brief discussion with Chris, we decided to revert the position of the call to lookupIfLocalAddrs so as to give the local host primacy over DNS. Latest (and hopefully last) webrev here: http://cr.openjdk.java.net/~robm/7180557/webrev.03/ -Rob On 14/09/13 00:00, Rob McKenna wrote: Hi Bernd, I should have said in the context of this bug. What I meant was removing AI_CANONNAME doesn't resolve the issue as far as Mac is concerned. I.e. I still see the UnknownHostException. In this particular case the hostname is not set via the hosts file. In the latest webrev the call to getifaddrs only occurs if getaddrinfo fails. -Rob On 13/09/13 20:28, Bernd Eckenfels wrote: Am 13.09.2013, 19:32 Uhr, schrieb Rob McKenna : W.r.t. the use of AI_CANONNAME, this doesn't actually make a difference in the context of this fix, but is definitely something that should be looked at. I'll put it on the todo list. I think it does make a difference: If you remove the CANON flag getaddrinfo() will not do DNS lookups when the host is configured to prefer the hosts file (which it should do on Linux and OSX). And so the platform specific lookupIfLocalhost() can be put after the getaddrinfo() (again). I actually think the bug "exists" on all platforms. If getaddrinfo() fails because neighter hosts nor DNS file finds the name this can happen on all platforms. I dont think it helps to add a fallback only on MACOSX (and there is certainly no need to prefer the fallback then). Gruss Bernd
hg: jdk8/tl/jdk: 8024253: ThreadLocal random can use SecureRandom for the initial seed
Changeset: 7913855ff66c Author:psandoz Date: 2013-09-20 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7913855ff66c 8024253: ThreadLocal random can use SecureRandom for the initial seed Reviewed-by: psandoz, chegar, alanb Contributed-by: Doug Lea , Peter Levart , Guy Steele ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java
hg: jdk8/tl/jdk: 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec
Changeset: c30dc8e7744e Author:psandoz Date: 2013-09-20 17:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c30dc8e7744e 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/PatternStreamTest.java - test/java/util/regex/PatternTest.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 58fd427b454d Author:sla Date: 2013-09-20 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58fd427b454d 8024985: com/sun/jdi/StepTest.java failed since jdk8b107 Reviewed-by: dcubed ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/JDIScaffold.java ! test/com/sun/jdi/PopAndStepTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/TestScaffold.java Changeset: 6a1c70e191d4 Author:sla Date: 2013-09-20 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1c70e191d4 8024416: TESTBUG: com/sun/jdi/MethodEntryExitEvents.java: method entry count mismatch Reviewed-by: dcubed ! test/com/sun/jdi/MethodEntryExitEvents.java
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Sean, It might be possible to set s.fd to delegate.fd before call to impl.accept and therefore merge if instanceOf block. -Dmitry On 2013-09-20 00:21, Seán Coffey wrote: > Looking for review on recently reported issue. Issue seen on windows > when a custom socketImpl is in use. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8024952 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/ > > Regards, > Sean. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code.
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Dmitry, You're right. I was cautious in moving the code up but since we're pointing at FileDescriptor Objs, we should be ok. Daniel Fuchs has pointed out another issue. Null delegate being passed into impl.accept if dealing with a custom socketImpl! It should just be impl.accept(s); I'll get this corrected and tested. Thanks for pointers. Sean. On 20/09/13 10:20, Dmitry Samersoff wrote: Sean, It might be possible to set s.fd to delegate.fd before call to impl.accept and therefore merge if instanceOf block. -Dmitry On 2013-09-20 00:21, Seán Coffey wrote: Looking for review on recently reported issue. Issue seen on windows when a custom socketImpl is in use. bug report : https://bugs.openjdk.java.net/browse/JDK-8024952 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/ Regards, Sean.
