jstack and the target output
david.holmes at oracle.com
Thu Nov 21 06:47:21 PST 2013
On 21/11/2013 11:47 PM, Piotr Bzdyl wrote:
> I recreated this problem in RedHat 6.4 installed in a virtual machine
> where I login as the same user on tty1 and tty2 - the setup for tmp is
> the same. I also tried with VM running Fedora 19 with 2 terminal windows
> in the X session. I tried to read files from /tmp/hsperfdata_$username/*
> from the terminal where I run jstack and I was able to read files (named
> after java processes pids).
I can recreate this using the minimal VM, which doesn't support
libattach. So it definitely seems like something is going wrong in the
attach process, but I can't say what. Not sure what debugging hooks we
have for the attach mechanism ??
> On Thu, Nov 21, 2013 at 2:42 PM, Staffan Larsen
> <staffan.larsen at oracle.com <mailto:staffan.larsen at oracle.com>> wrote:
> It could also be that one of the processes do not have access to
> /tmp (or that it is mapped differently).
> On 21 nov 2013, at 14:14, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
> > On 21/11/2013 13:06, Piotr Bzdyl wrote:
> >> Hello,
> >> I wasn't sure which OpenJDK mailing list I should choose for my
> question. As I have issues with jstack SA related group seemed the
> best place.
> >> I have the following issue:
> >> On console one (let's call it pts/1) I start a sample java app
> (let's say its pid is 1234). On another console (pts/2) I execute:
> >> jstack 1234
> >> As a result pts/2 displays:
> >> 1234: Unable to open socket file: target process not responding
> or HotSpot VM not loaded
> >> The -F option can be used when the target process is not responding
> >> And on pts/1 I see the thread dump printed. I would rather
> expect that the thread dump will be displayed on pts/2 and nothing
> will be printed to pts/1. I tried to use different versions of
> OpenJDK but the result was always the same.
> >> Could you provide me any hints what might be wrong?
> >> Best regards,
> >> Piotr
> > Are pts/1 and pts/2 the same user? Alternatively, any special
> options to the target VM that disables the attach mechanism?
> > In any case, I suspect the reason that pts/1 is print the stack
> trace is that the mechanism to start the attach mechanism in the
> target VM requires signalling the target VM with SIGQUIT, the same
> signal that is used to get a VM to do a thread dump to its own stdout.
> > -Alan
More information about the serviceability-dev