RFR 8163083: SocketListeningConnector does not allow invocations with port 0

Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However, the consequent call of startListening(

Re: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds

Hi Alex, The fix looks good to me. Thanks, Serguei On 9/17/18 10:49 AM, Alex Menkov wrote: Hi all, please review small fix: http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ It fixes https://bugs.openjdk.java.net/browse/JDK-8210725 - accordingly the logs of the failing tests, t

Re: Ping: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds

I have no further comments/questions. On 9/20/18 11:52 AM, JC Beyler wrote: Hi Alex, Looks good to me still :) Jc On Wed, Sep 19, 2018 at 5:21 PM Alex Menkov > wrote: Hi all, Ping. The bug has been labeled "timewaster" as it caused failures quite

Re: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4

On 9/20/18 4:11 PM, Alex Menkov wrote: Hi Chris, On 09/20/2018 15:07, Chris Plummer wrote: Hi Alex, Can you put "expected statement printed by jdb" in a static final since it is used in 2 places? Otherwise it looks good. I don't need to see an updated webrev. Not sure how it can be done. T

Re: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds"

Ok, so you're just suggesting that findPrompt() should require that the prompt be at the end of the line. In fact probably on a line by itself. Keep in mind that we also have issues with async printing that tends to result in the prompt appearing in the middle of some lines. We have most of the

Re: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4

Hi Chris, On 09/20/2018 15:07, Chris Plummer wrote: Hi Alex, Can you put "expected statement printed by jdb" in a static final since it is used in 2 places? Otherwise it looks good. I don't need to see an updated webrev. Not sure how it can be done. The text has to be explicitly specified i

Re: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds"

To be detected the output line should ends with "Boolean[1] " So "Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be instance of java.lang.Boolean[1] (id=706):" does not match. It seems to me that other bugs Gary is working have similar cases. --alex On 09/20/2018 15:27, Chri

Re: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again

BTW, this CR is still covering the kill002 failure, so you need to either include a fix for it also, or create a separate CR for it. I think a separate CR would be best because it is a different root cause. Chris On 9/20/18 2:47 PM, Chris Plummer wrote: Looks good. Still not bullet proof, but

Re: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds"

The regex you give would still detect Boolean[1] as a prompt, which we don't want. Chris On 9/20/18 3:22 PM, Alex Menkov wrote: May be it would be better to fix Jdb.receiveReplyFor to properly handle all replies like Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be instance

Re: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds"

May be it would be better to fix Jdb.receiveReplyFor to properly handle all replies like Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be instance of java.lang.Boolean[1] (id=706): jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: "[a-zA-Z0-9_-][a-zA-Z0-9_-

Re: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4

Hi Alex, Can you put "expected statement printed by jdb" in a static final since it is used in 2 places? Otherwise it looks good. I don't need to see an updated webrev. thanks, Chris On 9/20/18 10:24 AM, Alex Menkov wrote: Looks like JDK-4660756 fixed line number, but didn't fix source. I

Re: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds"

This one is a little different than exclude001 in that we don't control the name of the thread. We know (at least at the moment) that it is called "main", but that could always change. In general I'm fine with this fix, but if you have others like it, I'd suggest putting the "main" thread name

Re: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again

Looks good. Still not bullet proof, but I'm not sure it's possible to write tests like this in a way that will work no matter what output is produced by the method enter/exit events. Chris On 9/20/18 10:59 AM, Gary Adams wrote: The test failure has been identified due to the "int[2]" being mi

RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again

The test failure has been identified due to the "int[2]" being misrecognized as a compound prompt. This caused a cont command to be sent prematurely. The proposed fix waits for the correct prompt before advancing to the next command. Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/

RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds"

The corrupted output has been identified due to the "Boolean[1]" being misrecognized as a compound prompt. The proposed fix waits for the correct prompt before advancing to the next command. Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ Issue: https://bugs.openjdk.java.net/brows

Re: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4

Looks like JDK-4660756 fixed line number, but didn't fix source. I filled JDK-8210927 for this. New webrev: http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.02/ changes (vs ver .01): - updated comment in StringConvertTest.java about arrays; - RedefineTTYLineNumber was updated to verify li

[8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi, Kindly review the backport of "JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 JDK9 changeset - http://hg.openjdk.java.net/jdk9/jdk9/hotsp