JVM stuck/looping in futex call

[David Holmes]

Hi Sundar,

On 2/11/2019 5:39 am, Sundara Mohan M wrote:
> Hi,
>      I am running openjdk12/Linux on our systems and see jvm not responding
> to jstack or any diagnostic command (jcmd VM.info/Thread.print). Though
> application is running fine.

That would sound like the attach thread (which would respond to the 
jstack or other diagnostic command) is in some kind of bad state.

> I see following stack track
> 
> Process 115586 attached
> futex(0x7feeeffa19d0, FUTEX_WAIT, 116198, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=115587, si_uid=1000}
> ---
> futex(0x7feee8008bf8, FUTEX_WAKE_PRIVATE, 1) = 1
> rt_sigreturn()                          = 202
> futex(0x7feeeffa19d0, FUTEX_WAIT, 116198, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=115587, si_uid=1000}
> ---
> futex(0x7feee8008bf8, FUTEX_WAKE_PRIVATE, 1) = 1
> rt_sigreturn()                          = 202
> futex(0x7feeeffa19d0, FUTEX_WAIT, 116198, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=115587, si_uid=1000}
> ---
> futex(0x7feee8008bf8, FUTEX_WAKE_PRIVATE, 1) = 1
> rt_sigreturn()                          = 202
> futex(0x7feeeffa19d0, FUTEX_WAIT, 116198, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=115587, si_uid=1000}
> ---
> rt_sigreturn()                          = 202
> futex(0x7feeeffa19d0, FUTEX_WAIT, 116198, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=115587, si_uid=1000}
> ---
> rt_sigreturn()                          = 202
> futex(0x7feeeffa19d0, FUTEX_WAIT, 116198, NULL^CProcess 115586 detached
>   <detached ...>
> 
> Can someone help me understand what is happening here?

It appears that in responding to the SIGQUIT that is used to trigger the 
starting of the attach listener thread, that something is going wrong. 
We appear to be continually restarting an operation that still sees the 
signal pending - which doesn't really make sense to me. Can you get a 
complete stack trace using gdb?

> Please redirect me to proper ilist if this is not correct list for these
> type of questions.

This list is fine. It may end up being an issue for serviceability-dev 
but we can deal with that later. :)

Thanks,
David
-----

> 
> TIA
> Sundar
>