sue: https://bugs.openjdk.java.net/browse/JDK-8211736
Thanks!
--Daniil
On 10/17/18, 5:06 PM, "Daniil Titov" wrote:
Hi Chris,
The previous email was accidentally fired before I managed to type anything
in. Sorry for confusion.
Jdb constantly reads new commands fr
> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>> prove the fix is working (after fi
mer wrote:
>> Hi Alex,
>>
>> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>&g
>
> thanks,
>
> Chris
>
> On 10/11/18 8:02 PM, Daniil Titov wrote:
>>
>> Thank you, JC!
>>
>> Please review an updated version of the patch that fixes newly added
>> test for Windows platform (now it uses system
command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
,bpLine));
>
> thanks,
>
> Chris
>
> On 10/11/18 8:02 PM, Daniil Titov wrote:
>>
>> Thank you, JC!
>>
>> Please review an updated version of the patch that
http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
There is a space after the '('.
No need to send a new webrev for that evidently :),
Jc
On Thu, Oct 11, 2018 at 5:07
Please review the change that fixes the issue with missing prompt in jdb when a
breakpoint is hit and the suspend policy is set to stop the thread only.
Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
Thanks!
--Daniil
Hi Serguei,
Sure. That was my intention.
Thanks!
Bets regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Monday, October 8, 2018 at 6:17 PM
To: Daniil Titov , , Alex
Menkov , Chris Plummer
Cc: serviceability-dev
Subject: Re: RFR 8193879: Java debugger hangs
);
+ return (BreakpointEvent) waitForRequestedEvent(request);
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Monday, October 8, 2018 at 5:53 PM
To: Daniil Titov , Chris Plummer
,
Cc: serviceability-dev
Subject: Re: RFR 8193879: Java debugger hangs on method invocat
't see waitForSimplePrompt used in any existing tests.
>> Since it is only looking for a single character it could
>> produce false positives if the '>' was produced in the
>> output stream. Is this wait paired to the added prompt for the
>> br
> output stream. Is this wait paired to the added prompt for the
> break point event?
>
> 236 return waitForSimplePrompt ? waitForSimplePrompt(1,
> cmd.allowExit) : waitForPrompt(1, cmd.allowExit);
>
> It might be a good idea to include a test with multiple
Hi Fairoz,
The backport looks good for me.
Thanks!
--Daniil
On 10/3/18, 10:28 PM, "serviceability-dev on behalf of Fairoz Matte"
wrote:
Hi,
Kindly review the backport of "JDK-8163083: SocketListeningConnector does
not allow invocations with port 0" to 8u
Webrev - http:
Please review the changes that fix the deadlock in the debugger when the
debugger is running with the tracing option on.
The problem here is that when the tracing is on the "JDI Target VM Interface"
thread (the thread that reads all replies and then notifies the thread that
sent the request th
Hi Alex,
The fix looks good for me.
Thanks.
-Daniil
On 9/28/18, 2:28 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
please take a look ar a fix for
https://bugs.openjdk.java.net/browse/JDK-8209332
webrev:
http://cr.openjdk.java.net/~amenkov/sh2java
at 11:33 AM
To: Daniil Titov , JC Beyler
Cc: , ,
Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations
with port 0
Just noticed one more minor issue:
+import java.util.Collection;
+import java.util.Iterator;
+import java.util.LinkedHashMap;
It seems the above
at 8:12 PM
To: Daniil Titov , JC Beyler
Cc: , ,
Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations
with port 0
Hi Daniil,
It is great that you came up the fix for this issue.
Thanks to Gary for the help too.
I wonder if we could get away without updating the
: SocketListeningConnector does not allow invocations
with port 0
Hi Daniil,
Still looks good to me :)
Nit: empty line 83 of the new test is not required!
Jc
On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov wrote:
Hi Alex,
Please review the updated webrev that has new test moved to
ex Menkov wrote:
> +1
>
> --alex
>
> On 09/24/2018 10:39, Gary Adams wrote:
>> Looks good to me.
>>
>> On 9/24/18, 1:25 PM, Daniil Titov wrote:
>>> Hi Alex and Gary,
>>>
>>> Please rev
port updated
> startListening(args1) // already listening
>
>
> On 9/20/18 10:59 PM, Daniil Titov wrote:
>> Please review the change that fixes the issue in
com.sun.tools.jdi.SocketListenerConnector.startListening() method.
>>
>> Whe
Thanks,
Jc
On Thu, Sep 20, 2018 at 8:00 PM Daniil Titov <mailto:daniil.x.ti...@oracle.com>
wrote:
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
un
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(
Thank you, JC, Serguei, and Alex for reviewing this change. I will correct
comments as suggested before pushing this change in the repository.
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Thursday, August 30, 2018 at 3:43 PM
To: Daniil Titov , JC Beyl
y suggestion is to get rid of "suspended" parameter and all non-suspended
call of the checkThreads.
But, please, note, the comments will need another update. :)
Jc, nice catch about the comments!
Thanks,
Serguei
On 8/27/18 17:57, Daniil
Hi JC, Serguei, and Alex,
Please review an updated version of the webrev that has these comments fixed.
Webrev: http://cr.openjdk.java.net/~dtitov/8209585/webrev.02/
Issue: https://bugs.openjdk.java.net/browse/JDK-8209585
Thanks!
Daniil
From: serviceability-dev on
behalf of Daniil Titov
cause I worry about simplifying a test for Graal but losing
coverage in the general case,
Jc
On Thu, Aug 23, 2018 at 8:29 PM Daniil Titov wrote:
Please review the change that fixes 4 JVMTI tests when running with Graal.
One of the checks these tests perform compares the number of fra
coverage in the general case,
Jc
On Thu, Aug 23, 2018 at 8:29 PM Daniil Titov wrote:
Please review the change that fixes 4 JVMTI tests when running with Graal.
One of the checks these tests perform compares the number of frames in the
thread's stack returned by JVMTI GetF
Please review the change that fixes 4 JVMTI tests when running with Graal.
One of the checks these tests perform compares the number of frames in the
thread's stack returned by JVMTI GetFrameCount() with the number of frames
entries returned by JVMTI GetStackTrace(). The thread to be tested exec
gt; Thanks,
> Serguei
>
>
>
> On 8/16/18 19:04, Daniil Titov wrote:
>> Please review the change that fix the test failure when running with
>> Graal.
>>
>> There are 2 problems here. The first one is that when running wit
Please review the change that fix the test failure when running with Graal.
There are 2 problems here. The first one is that when running with Graal the
number of local references reported by JVMTI FollowReferences () to the
callback exceeds the size of the array ( 100 ) the test uses for stori
Looks good to me.
Best regards,
Daniil
On 8/16/18, 3:20 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
please review small change to problemlist BreakpointWithFullGC.java
until JDK-8209605 is fixed.
#
te looks good.
>
> Chris
>
> On 7/26/18 9:56 AM, Daniil Titov wrote:
>> Hi Chris,
>>
>> The smallest allowed metaspace size for the test is 9MB. In both
>> cases (when the metaspace size is set to 9Mb and to 16 Mb) the
>>
; Serguei
>
>
> On 7/25/18 16:11, Daniil Titov wrote:
>> Hello,
>>
>> Please review the change that fix the test issue. The fix increases
>> the metaspace size and corrects the path to the class files.
>>
>
aspaceSizeConstraintFunc,
AfterErgo)\
Best regards,
Daniil
On 7/25/18, 4:32 PM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
It looks good to me.
What is the need to increase the metaspace size?
Thanks,
Serguei
On 7/25/18 16:11, Daniil Titov
Hello,
Please review the change that fix the test issue. The fix increases the
metaspace size and corrects the path to the class files.
Webrev: http://cr.openjdk.java.net/~dtitov/8207364/webrev.01/
Issue: https://bugs.openjdk.java.net/browse/JDK-8207364
Thanks!
Best regards,
Daniil
Looks good to me.
--Daniil
On 7/25/18, 11:23 AM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi,
please review the following for for
https://bugs.openjdk.java.net/browse/JDK-8199155
webrev:
http://cr.openjdk.java.net/~amenkov/accessibility/webrev/
Thank you Chris and Serguei for reviewing this change!
Best regards,
Daniil
From: Chris Plummer
Date: Thursday, July 19, 2018 at 11:03 AM
To: Daniil Titov , "serguei.spit...@oracle.com"
, "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net&quo
: Daniil Titov , "serguei.spit...@oracle.com"
, "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8204695: [Graal]
vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java
fails
return true;
264 }
265 }
266 );
267
Best regards,
Daniil
From: Chris Plummer
Date: Thursday, July 19, 2018 at 10:31 AM
To: Daniil Titov , "serguei.spit...@oracle.com"
, "serviceability-dev@openjdk.
received at the moment when
the listener was unregistered.
Best regards,
Daniil
From: Chris Plummer
Date: Thursday, July 19, 2018 at 10:11 AM
To: Daniil Titov , "serguei.spit...@oracle.com"
, "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net&quo
.spit...@oracle.com"
Date: Tuesday, July 17, 2018 at 7:59 PM
To: Daniil Titov ,
"serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8204695: [Graal]
vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameF
4:53 PM
To: Daniil Titov ,
"serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8204695: [Graal]
vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java
fails
Hi Daniil,
Thank you for c
racle.com"
Date: Tuesday, July 17, 2018 at 4:53 PM
To: Daniil Titov ,
"serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8204695: [Graal]
vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter0
nges you suggested.
Webrev: http://cr.openjdk.java.net/~dtitov/8204695/webrev.02/
Thanks!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, July 17, 2018 at 1:34 PM
To: Daniil Titov ,
"serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net"
Please review the change that fix the JDI test when running with Graal.
The problem here is that the test verifies that a class prepare event is
generated when the target VM loads a specific test class, but with Graal turned
on additional class prepare events are generated by the compiler thread
Please review the change that filters out 8 JDI and JDWP tests when running
with Graal. These tests consume all memory ( to force GC or to test that the
OutOfMemory error is thrown ) that sporadically results in the exceptions in
the Graal compiler threads and failure.
Issue: https://bugs.open
gt; Thanks,
> Serguei
>
>
> On 7/11/18 22:23, Daniil Titov wrote:
>> Please review the changes that fix jdb issue with evaluation of
>> multidimensional arrays of primitives.
>>
>> The problem here is that for N-dimensional arrays of th
Please review the changes that fix jdb issue with evaluation of
multidimensional arrays of primitives.
The problem here is that for N-dimensional arrays of the primitives with N
greater then 2, JDI fails to find its component type (which is an array of
dimension N-1) assuming that it is a boot
Please review the changes that fix 4 JDI tests that fail when running with
Graal.
The problem here is that in some cases by the time the test decides whether the
JDI event should be saved for further analysis the object this event refers to
might be already collected in the debuggee VM. The fix
Please review the changes that fix 15 tests failures when running with Graal.
The main problem here is that the tests assume that no garbage collection
happens before the tests complete their checks. The other problem is that the
tests could not strictly distinguish the objects created by the de
y, June 12, 2018 at 1:08 PM
To: Daniil Titov , Chris Plummer
, "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8203809: [Graal] JDI tests fail with: JDITestRuntimeException
: ** event IS NOT a breakpoint **
Hi Daniil,
On 6/12/18 12:30, Dan
,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, June 12, 2018 at 12:21 PM
To: Chris Plummer , Daniil Titov
, "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8203809: [Graal] JDI tests fail with: JDITestRuntimeExce
: "serguei.spit...@oracle.com"
Date: Monday, June 11, 2018 at 6:18 PM
To: Daniil Titov ,
"serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8203809: [Graal] JDI tests fail with: JDITestRuntimeException
: ** event IS NOT a breakpoint *
Please review the changes that fix failure of 6 JDI tests run with Graal.
The problem here is that currently the tests filter out only 2 specific JFR
events (nsk.share.jdi.EventsFilter.filtered()) before analyzing them and fail
if the received event doesn't match the expected one. But with Graa
issue for that as
that changes will affect multiple tests.
Webrev: http://cr.openjdk.java.net/~dtitov/8203033/webrev.04/
Issue: https://bugs.openjdk.java.net/browse/JDK-8203033
Thanks,
Daniil
From: "serguei.spit...@oracle.com"
Date: Wednesday, June 6, 2018 at 12:18 PM
To: Da
-8203033
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Wednesday, June 6, 2018 at 11:23 AM
To: Daniil Titov ,
Subject: Re: RFR 8203033: [Testbug]
vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic002/TestDescription.java
fails with nestmates
Hi D
Please review the change that fixes
vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic002/TestDescription.java
test.
The fix uses the implementation of a parametrized interface in the test class
to trigger the compiler to generate a synthetic bridge method. The test works
fine in both n
ay, May 31, 2018 at 10:33 AM
To: Daniil Titov , Thomas Stüfe
, "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net"
Cc:
Subject: Re: RFR 8197387: jcmd started by "root" must be allowed to access all
VM processes
Hi Daniil,
It looks good to
, "Thomas Stüfe" wrote:
On Wed, May 30, 2018 at 7:27 PM, Daniil Titov
wrote:
> Hi Thomas,
>
> Thank you for the review. Just in in case I put an updated webrev with
suggested changes at http://cr.openjdk.java.net/~dtitov/8197387/webrev.03/ .
>
>
t since this logic is not touched by your change, your
change is okay.
Best Regards, Thomas
On Tue, May 29, 2018 at 11:33 PM, Daniil Titov
wrote:
> Hi Thomas,
>
> Please review a new version of the fix that includes the changes
suggeste
Hi Serguei,
Thank you, for review.
I will need one more reviewer to push this changes.
Best regards,
Daniil
On 5/29/18, 12:01 PM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
It looks good.
Thanks,
Serguei
On 5/26/18 11:57, Daniil T
On Thu, May 24, 2018 at 3:11 AM, Daniil Titov
wrote:
> Please review the changes that fix JDK-8197387.
>
> There are 2 problems here:
> 1. JVM ignores .attach_pid file if it is owned by the user
different from the one that owns this JVM process
> 2. j
Please review the changes that fix a build failure for Jvmti tests.
The fix replaces printf "%ld" format with JLONG_FORMAT macro defined in the
same way as it is defined in the hotspot
(src/hotspot//share/utilities/globalDefinitions.hpp and
src/hotspot//share/utilities/globalDefinitions_gcc.hpp
Is it always desirable? I'd like to
know
> what a sys admin might think of this. :)
>
> Further root can always "su" to another user and run jcmd that way.
>
> Cheers,
> David
>
>
> On 24/05/2018 11:11 AM, Daniil Titov wrote:
>&g
Please review the changes that fix JDK-8197387.
There are 2 problems here:
1. JVM ignores .attach_pid file if it is owned by the user different from
the one that owns this JVM process
2. jcmd checks that .java_pid socket is owned by the same user that runs
jcmd and reports an error otherwise
>> and then the implementation brought into alignment. But that should
>> have happened many years ago. Changing this now seems risky to me.
>>
>> This change in long standing behaviour also requires a CSR request if
>> it is to proceed.
>>
&g
On 3/29/18 10:27, Daniil Titov wrote:
> Please review the changes that ensure that no operation on deleted
com.sun.jdi.request.EventRequest objects are permitted as per JDI specification
for
com.sun.jdi.request.EventRequestManager.deleteEventRequest(com.sun.jdi.request.EventRequest)
met
Please review the changes that ensure that no operation on deleted
com.sun.jdi.request.EventRequest objects are permitted as per JDI specification
for
com.sun.jdi.request.EventRequestManager.deleteEventRequest(com.sun.jdi.request.EventRequest)
method. The fix makes the following 4 methods in c
Please review the changes that fix intermittent timeout failure of
serviceability/dcmd/framework/* tests.
The problem here is that these tests invoke jcmd in different ways and one of
such ways is when a main class is passed to the jcmd as a VM identifier. The
main class for jtreg test is com.s
t
>>>>> stream but rather from the DataInputStream object that is
>>>>> constructed in JdwpReply.initFromStream(InputStream) method. With
>>>>> the proposed fix we do ensure that the created DataInputStream
>>>>> object contains data from
e: Tuesday, February 20, 2018 at 7:31 PM
To: Daniil Titov ,
"serviceability-dev@openjdk.java.net"
Subject: Re: RFR 8170541: serviceability/jdwp/AllModulesCommandTest.java fails
intermittently on Windows and Solaris
Hi Daniil,
It looks good to me.
It seems, you have been able to re
Hi Serguei,
A new version of the webrev that has these strings reformatted is at
http://cr.openjdk.java.net/~dtitov/8170541/webrev.02/
Thank you!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, February 20, 2018 at 3:00 PM
To: Da
Please review the changes that fix intermittent failure of
serviceability/jdwp/AllModulesCommandTest.java test.
The problem here is that for a large data the JDWP agent
(socketTransport_writePacket() method in
src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c ) sends 2
packets and
Hi Daniil,
>>
>> Have you run with -Xcomp. I'm concerned that inlining will cause the
>> test to fail because stack depths will not be as expected. Also, if
>> you find the owned monitor, but the depth is not as expected, I think
>> you a
27;d better to rephrase the messages above to tell about actual values
vs expected.
It normally simplifies the analysis of failures as there is no need to find
what values were printed before and that they are exactly what needed
for comparison.
Thanks,
Serguei
Got it.
+1
Thanks!
Best regards,
Daniil
On 1/16/18, 1:00 PM, "Alex Menkov" wrote:
On 01/16/2018 12:11, Daniil Titov wrote:
> Hi Alex,
>
> The fix looks good. The only question I have is regarding the changes in
jvmti.xml where element
Hi Alex,
The fix looks good. The only question I have is regarding the changes in
jvmti.xml where element was introduced, e.g.:
-
+
element indicates a block of text quoted from an external source
so if this element was used here for indentation purposes only probably
>> It'd better to rephrase the messages above to tell about actual
>> values vs expected.
>> It normally simplifies the analysis of failures as there is no need
>> to find
>> what values were printed before and that they are exactly what neede
Hello,
Please review the following fix that adds a jtreg test for
GetOwnedMonitorStackDepthInfo JVMTI function.
Bug: https://bugs.openjdk.java.net/browse/JDK-8153629
Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00
The tests ran successfully with Mach5.
Best regards,
Daniil
writer.println("");
border, cellpadding, cellspacing, width are also unsupported in HTML5
It's unclear why tidy doesn't report them.
Could you try to run W3 validator (https://validator.w3.org/)
--alex
On 12/22/2017 09:39, Daniil Titov w
Please review a fix for the doc bug.
The fix does the following:
1. Removes empty elements.
2. Adds an outer element to the index section .
3. Removes obsolete in HTML5 “summary” attribute in elements.
4. Removes empty elements.
5. Replaces n
Please review a fix for the doc bug.
The fix does the following:
1. Removes empty elements.
2. Adds an outer element to the index section .
3. Removes obsolete in HTML5 “summary” attribute in elements.
4. Removes empty elements.
5. Replaces not supported in HTML5 “bgcolor”
301 - 381 of 381 matches
Mail list logo
