A Bug about the JVM Attach mechanism

[Leonid Mesnik]

I think it is
https://bugs.openjdk.java.net/browse/JDK-8225193 <https://bugs.openjdk.java.net/browse/JDK-8225193>

The jcmd failed to attach if /tmp/.java_pid* is removed. It doesn't find file which is used as listener socket  and send signal to start attach listener. (It suppose that listener is not started yet). While target VM expect that listener is started already and just dump stack trace into stdout.


See code
http://hg.openjdk.java.net/jdk/jdk/file/eaf0a8de3450/src/hotspot/share/runtime/os.cpp#l362 <http://hg.openjdk.java.net/jdk/jdk/file/eaf0a8de3450/src/hotspot/share/runtime/os.cpp#l362>
http://hg.openjdk.java.net/jdk/jdk/file/eaf0a8de3450/src/hotspot/share/services/attachListener.hpp#l74 <http://hg.openjdk.java.net/jdk/jdk/file/eaf0a8de3450/src/hotspot/share/services/attachListener.hpp#l74>

The listener is initialized only once when thread is started and still left "initialized" even socket is removed.

The only workaround is not to remove this file. 

Leonid

> On Jun 19, 2019, at 9:12 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 19/06/2019 2:10 pm, nijiaben wrote:
>> Hi,
>> > Can you provide a bug number for this?
>> I'm sorry, I made you misunderstand what I meant.
>> I mean, I knew this problem before, but I didn't submit it to the JDK Bug System.
> 
> Okay.
> 
>> > Once we have attached and created the attach thread we don't need to
>> > perform that initialization handshake because the attach thread exists
>> > and will process any subsequent commands.
>> I know this mechanism, can we provide means of recovery to avoid unavailability caused by accidental deletion?
> 
> Sorry I'm still not clear how deletion causes any problem after the attach thread has been started ??
> 
> David
> -----
> 
>> Thanks,
>> nijiaben @ PerfMa
>> ------------------ Original ------------------
>> *From: * "David Holmes"<david.holmes at oracle.com>;
>> *Date: * Thu, Jun 20, 2019 11:36 AM
>> *To: * "nijiaben"<nijiaben at perfma.com>; "serviceability-dev"<serviceability-dev at openjdk.java.net>; "jdk8u-dev"<jdk8u-dev at openjdk.java.net>; "hotspot-runtime-dev"<hotspot-runtime-dev at openjdk.java.net>;
>> *Subject: * Re: A Bug about the JVM Attach mechanism
>> Hi,
>> On 19/06/2019 2:26 am, nijiaben wrote:
>> > Hi, All,
>> >
>> > There is a bug that has been discovered for a long time, but it has not
>> > been fixed.
>> Can you provide a bug number for this?
>> > We usually use some shell scripts to clean up the /tmp directory.
>> > When we have executed a similar jstack command based on the attach
>> > mechanism,
>> > it will generate a .java_pidXXX socket file in the /tmp directory.
>> > Once this file is clean up, and then will not be attached anymore.
>> >
>> > The main reason is that once the Attach Listener thread is created,
>> > the file of  “/tmp/.java_pidXXX” will be created and the markup
>> > initialization is complete.
>> > If .java_pidXXX is cleaned up, it will not be created anymore and cannot
>> > be attached.
>> Once we have attached and created the attach thread we don't need to
>> perform that initialization handshake because the attach thread exists
>> and will process any subsequent commands.
>> David
>> -----
>> >
>> > bool AttachListener::is_init_trigger() {
>> > if (init_at_startup() || is_initialized()) { // initialized at startup
>> > or already initialized
>> > return false;
>> > }
>> > char fn[PATH_MAX+1];
>> > sprintf(fn, ".attach_pid%d", os::current_process_id());
>> > int ret;
>> > struct stat64 st;
>> > RESTARTABLE(::stat64(fn, &st), ret);
>> > if (ret == -1) {
>> > snprintf(fn, sizeof(fn), "%s/.attach_pid%d",
>> > os::get_temp_directory(), os::current_process_id());
>> > RESTARTABLE(::stat64(fn, &st), ret);
>> > }
>> > if (ret == 0) {
>> > if (st.st_uid == geteuid()) {
>> > init(); // will create Attach Listener Thread
>> > return true;
>> > }
>> > }
>> > return false;
>> > }
>> >
>> > This bug has a big impact on troubleshooting some problems.
>> > Can it be fixed as soon as possible?
>> >
>> > Thanks,
>> >
>> > nijiaben @ PerfMa
>> >