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

[serguei . spitsyn]

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


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/
    <http://cr.openjdk.java.net/%7Eysuenaga/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