RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Yasumasa Suenaga-4
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
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

serguei.spitsyn@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.

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

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Yasumasa Suenaga-4
2019年7月17日(水) 8:35 <[hidden email]>:
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.


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

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Chris Plummer
On 7/16/19 4:41 PM, Yasumasa Suenaga wrote:

> 2019年7月17日(水) 8:35 <[hidden email]
> <mailto:[hidden email]>>:
>
>     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.

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
>


Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

serguei.spitsyn@oracle.com
In reply to this post by Yasumasa Suenaga-4
Okay, thank you for explanation.
The fix looks good to me.

Thanks,
Serguei

On 7/16/19 4:41 PM, Yasumasa Suenaga wrote:
2019年7月17日(水) 8:35 <[hidden email]>:
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.


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


Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Chris Plummer
In reply to this post by Chris Plummer
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 <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>     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
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Chris Plummer
On 7/16/19 4:54 PM, Chris Plummer wrote:

> 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 <[hidden email]
>>> <mailto:[hidden email]>>:
>>>
>>>     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.
>
And yes, the change looks good. Thanks for the quick fix.

Chris

> 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
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Yasumasa Suenaga-4
Hi Chris, Serguei,

Thank you for your quick review.
I will push it when I receive the result from submit repo.


Yasumasa


2019年7月17日(水) 8:55 Chris Plummer <[hidden email]>:
On 7/16/19 4:54 PM, Chris Plummer wrote:
> 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 <[hidden email]
>>> <mailto:[hidden email]>>:
>>>
>>>     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.
>
And yes, the change looks good. Thanks for the quick fix.

Chris

> 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
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"

Yasumasa Suenaga-4
2019年7月17日(水) 9:02 Yasumasa Suenaga <[hidden email]>:
Hi Chris, Serguei,

Thank you for your quick review.
I will push it when I receive the result from submit repo.

I received the result from submit repo, this change works fine.

mach5-one-ysuenaga-JDK-8227738-20190716-2315-3843771

I will push it tonight (in Japan)


Yasumasa


2019年7月17日(水) 8:55 Chris Plummer <[hidden email]>:
On 7/16/19 4:54 PM, Chris Plummer wrote:
> 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 <[hidden email]
>>> <mailto:[hidden email]>>:
>>>
>>>     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.
>
And yes, the change looks good. Thanks for the quick fix.

Chris

> 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
>>>
>>
>>
>