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 <serguei.spitsyn at oracle.com 
> <mailto:serguei.spitsyn at 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.

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
>