A Bug about the JVM Attach mechanism
David Holmes
david.holmes at oracle.com
Thu Jun 20 03:36:28 UTC 2019
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
>
More information about the jdk8u-dev
mailing list