jstack and the target output

[David Holmes]

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

David
------

>
>
> 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).
>
>     /Staffan
>
>     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
>
>