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