On 7/16/19 4:46 PM, Chris Plummer wrote:
On 7/16/19 4:41 PM, Yasumasa Suenaga wrote:
2019年7月17日(水) 8:35 <serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com>>:
Hi Yasumasa,
Thank you for taking care about this issue!
You changed the code form this:
371 } else if (cur_state == AL_NOT_INITIALIZED) {
372 // Start to initialize.
373 if (!AttachListener::is_init_trigger()) {
374 // Attach Listener could not be started.
375 // So we need to transit the state to
AL_NOT_INITIALIZED.
376 AttachListener::set_state(AL_NOT_INITIALIZED);
377 }
378 continue;
379 } else if (AttachListener::check_socket_file()) {
to this:
371 } else if (cur_state == AL_NOT_INITIALIZED) {
372 // Start to initialize.
373 if (AttachListener::is_init_trigger()) {
374 // Attach Listener has been initialized.
375 // Accept subsequent request.
376 continue;
377 } else {
378 // Attach Listener could not be started.
379 // So we need to transit the state to
AL_NOT_INITIALIZED.
380 AttachListener::set_state(AL_NOT_INITIALIZED);
381 }
382 } else if (AttachListener::check_socket_file()) {
The only difference I see is that now the continue statement is
missed
after the AttachListener::set_state(AL_NOT_INITIALIZED).
Just want to make sure that it was your intention.
Yes, we should go through when is_init_trigger() returns false.
I had the same question. So now my question is why is it returning
false? I thought this was an error condition indicating we failed to
initialize the attach mechanism, so I would expect this to later cause
the attach to fail. On the other hand, I have verified that the fix
seems to work.
Nevermind. I see now that AttachListener::is_init_trigger() returns true
if the signal was being sent in order to attach, indicated by presence
of the .attach_pid<pid> flag. So when it returns false, that means we
want the stack trace dump instead of setting up an attach.
Chris
thanks,
Chris
Thanks,
Yasumasa
Thanks,
Serguei
On 7/16/19 4:15 PM, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8227738
webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8227738/webrev.00/
After JDK-8225690, HotSpot could not handle JVMTI dump request
(includes thread dump request).
It is caused by incorrect handling of
AttachListener::is_init_trigger().
I fixed it in this webrev, and it works fine on
serviceability/attach and
vmTestbase/nsk/jvmti/DataDumpRequest/datadumpreq001.
Also I pushed this to submit repo (I have not yet received the
result).
http://hg.openjdk.java.net/jdk/submit/rev/3fb4b04ff5f2
Thanks,
Yasumasa
