A Bug about the JVM Attach mechanism

[David Holmes]

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