[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Stack unwinder for SA
From:       Yasumasa Suenaga <suenaga () oss ! nttdata ! com>
Date:       2021-01-25 4:15:26
Message-ID: 897a8c43-0b90-07bd-791a-22eb304a0167 () oss ! nttdata ! com
[Download RAW message or body]

Hi David, Chris,

I want to fix `jhsdb jstack --mixed` in JDK-8245234 with third-party library at \
first. Fixing hs_err log is an another issue IMHO, but I just want to say we may \
divert it for hs_err log. We need further discussion for it of course.


Thanks,

Yasumasa


On 2021/01/25 12:32, Chris Plummer wrote:
> On 1/24/21 7:14 PM, David Holmes wrote:
> > On 25/01/2021 12:41 pm, Yasumasa Suenaga wrote:
> > > Hi all,
> > > 
> > > Chris and I discussed about fixing JDK-8245234 to see all mixed stacks via \
> > > `jhsdb jstack --mixed`. In the discussion, we agree to use stack unwinder, but \
> > > we haven't yet decided which library to use. Can you suggest the stack unwinder \
> > > for SA? 
> > > I fixed similar issue in JDK-8234624 to understand DWARF in SA for Linux, \
> > > however it does not support DWARF completely because it is too complex to \
> > > implement by scratch. AMD64 SysV ABI [1] says DWARF is used for stack \
> > > unwinding. So we need to support DWARF completely if we want to unwind. 
> > > There are some stack unwinder. I think libunwind [2] is suitable for this \
> > > purpose, however I'm not sure it is the best solution. And also I saw similar \
> > > issue on Windows because we cannot depend on base pointer (like SA) in Windows \
> > > x64 [3]. So I want to use the library which is support both Linux and Windows. 
> > > We also think introducing stack unwinder helps improving native call stacks in \
> > > hs_err log. It will help troubleshooters.
> > 
> > Immediate reaction to this part is that I would not want third-party libraries \
> > getting involved in hs_err file generation. Given we often do this from a signal \
> > handling context, it would be far too risky IMO. 
> This is probably much less of an issues for hs_err stack dumps than for SA, since \
> the crashed thread is almost always in JDK code, so we can still get the stack \
> trace for the hs_err file. The issue with SA and JDK-8234624 is when you try to \
> dump all threads (with --mixed). Any that are waiting in a clib function only show \
> the frame they are in. In debug.cpp there are a couple of thread dumping APIs that \
> probably also suffer from the problem described in JDK-8245234, so that's possibly \
> where some hotspot improvements could be made. 
> Chris
> > Cheers,
> > David
> > -----
> > 
> > > 
> > > I want to hear your opinions!
> > > 
> > > 
> > > Thanks,
> > > 
> > > Yasumasa
> > > 
> > > 
> > > [1] https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf
> > >  [2] https://github.com/libunwind/libunwind
> > > [3] https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64#unwind-procedure
> > > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]