A Bug about the JVM Attach mechanism

[David Holmes]

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
>