JVM stuck/looping in futex call

[David Holmes]

On 5/11/2019 8:43 am, Sundara Mohan M wrote:
> HI David,
>      Did you mean to get stack trace of that process? I could attach to 
> gdb but not sure where to keep breakpoint.
> More info on how to get this will be helpful.

I need to see the stack before we hit the looping call, to see what it 
is that triggers the loop. Can you tell what thread is involved?

Is there something special/different about your Linux environment? Do 
you have native threads attached to the VM?

Thanks,
David

> 
> Thanks
> Sundar
> 
> On Fri, Nov 1, 2019 at 4:03 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     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
>      >
>