RFR: 8263636: Add --disableregistry option to jhsdb debugd

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFR: 8263636: Add --disableregistry option to jhsdb debugd

Yasumasa Suenaga-7
`jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.

This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

-------------

Commit messages:
 - 8263636: Add --disableregistry option to jhsdb debugd

Changes: https://git.openjdk.java.net/jdk/pull/3233/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263636
  Stats: 162 lines in 4 files changed: 151 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3233/head:pull/3233

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd

Chris Plummer-2
On Sun, 28 Mar 2021 07:53:31 GMT, Yasumasa Suenaga <[hidden email]> wrote:

> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>
> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

Overall the changes look good. I just have some minor suggestions for comments, code formatting, and help output.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 89:

> 87:         if (canConnectToRemote) {
> 88:             System.out.println("          or  jhsdb " + mode + " --connect debugserver");
> 89:             System.out.println("          or  jhsdb " + mode + " --connect id@debugserver:1234");

You change here makes it look like if you specify `id@` then you also need to specify the port. I'd suggest also including the original line that just has `id@debugserver`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 103:

> 101:                 " This option overrides the system property 'sun.jvm.hotspot.rmi.port'. If not specified," +
> 102:                 " the system property is used. If the system property is not set, the default port 1099 is used.");
> 103:         System.out.println("    --disableregistry       Do not start RMI registry (to use RMI registry that exists)");

"to use RMI registry that exists" doesn't read well. Do you mean "use already started RMI registry"?

src/jdk.hotspot.agent/share/man/jhsdb.1 line 188:

> 186: If not specified, RMI registry will be started on startup.
> 187: Otherwise will it not start, the RMI registry (rmid, etc) is needed
> 188: before starting debugd.

Is this what you mean: `Otherwise it will not be started, and the already started RMI registry will be used instead.`

test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdRmidTest.java line 37:

> 35:  * @test
> 36:  * @bug 8263636
> 37:  * @requires vm.hasSA

Can you add an `@summary` comment?

test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdRmidTest.java line 58:

> 56:                                 .redirectError(ProcessBuilder.Redirect.INHERIT)
> 57:                                 .start();
> 58:         Thread.sleep(3000);  // Sleep 3 sec for waiting to start rmid.

"Sleep 3 sec to wait for rmid to start".

test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java line 41:

> 39:
> 40:     private boolean disableRegistry;
> 41:

I'd suggest removing the existing empty lines rather than follow the pattern of adding them.

-------------

Changes requested by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Yasumasa Suenaga-7
In reply to this post by Yasumasa Suenaga-7
> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>
> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3233/files
  - new: https://git.openjdk.java.net/jdk/pull/3233/files/c09b2177..02d2b259

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=00-01

  Stats: 11 lines in 4 files changed: 2 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3233/head:pull/3233

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Yasumasa Suenaga-7
In reply to this post by Chris Plummer-2
On Fri, 2 Apr 2021 20:34:37 GMT, Chris Plummer <[hidden email]> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   Fix comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 89:
>
>> 87:         if (canConnectToRemote) {
>> 88:             System.out.println("          or  jhsdb " + mode + " --connect debugserver");
>> 89:             System.out.println("          or  jhsdb " + mode + " --connect id@debugserver:1234");
>
> Your change here makes it look like if you specify `id@` then you also need to specify the port. I'd suggest also including the original line that just has `id@debugserver`.

I reverted the original line in new commit.

We can also specify port number without `id@` (e.g. `--connect debugserver:1234`). Is it ok not to describe on help message? IMHO it is not good to describe all patterns because it might be verbosely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Chris Plummer-2
On Mon, 5 Apr 2021 00:27:35 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 89:
>>
>>> 87:         if (canConnectToRemote) {
>>> 88:             System.out.println("          or  jhsdb " + mode + " --connect debugserver");
>>> 89:             System.out.println("          or  jhsdb " + mode + " --connect id@debugserver:1234");
>>
>> Your change here makes it look like if you specify `id@` then you also need to specify the port. I'd suggest also including the original line that just has `id@debugserver`.
>
> I reverted the original line in new commit.
>
> We can also specify port number without `id@` (e.g. `--connect debugserver:1234`). Is it ok not to describe on help message? IMHO it is not good to describe all patterns because it might be verbosely.

It's hard to say what's best here. You don't want to give examples that may be misleading, but in some cases including every possible example can become too verbose. It looks like there are 4 possible examples here; with and w/o `id` and with and w/o the port. Including 3 of the 4 makes me think you should just add the 1 missing one to make it complete. On the other hand, maybe you could go with just the `id@debugserver:1234` example and leave the other 3 off. The syntax does clearly show the `id` and port are optional.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Chris Plummer-2
In reply to this post by Yasumasa Suenaga-7
On Mon, 5 Apr 2021 00:25:38 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>>
>> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>
>   Fix comments

test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdRmidTest.java line 51:

> 49:         JDKToolLauncher rmidLauncher = JDKToolLauncher.createUsingTestJDK("rmid");
> 50:         rmidLauncher.addToolArg("-J-Dsun.rmi.activation.execPolicy=none");
> 51:         rmidLauncher.addToolArg("-J--add-modules=jdk.hotspot.agent");

Is this really needed? Although SA will be using rmid, I don't understand why rmid needs to know about SA.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v3]

Yasumasa Suenaga-7
In reply to this post by Yasumasa Suenaga-7
> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>
> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix help message for --connect

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3233/files
  - new: https://git.openjdk.java.net/jdk/pull/3233/files/02d2b259..93c6f13e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3233/head:pull/3233

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v3]

Yasumasa Suenaga-7
In reply to this post by Chris Plummer-2
On Mon, 5 Apr 2021 20:57:34 GMT, Chris Plummer <[hidden email]> wrote:

> On the other hand, maybe you could go with just the id@debugserver:1234 example and leave the other 3 off. The syntax does clearly show the id and port are optional.

Agree, I left `id@debugserver:1234` only in new commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Yasumasa Suenaga-7
In reply to this post by Chris Plummer-2
On Mon, 5 Apr 2021 20:50:30 GMT, Chris Plummer <[hidden email]> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   Fix comments
>
> test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdRmidTest.java line 51:
>
>> 49:         JDKToolLauncher rmidLauncher = JDKToolLauncher.createUsingTestJDK("rmid");
>> 50:         rmidLauncher.addToolArg("-J-Dsun.rmi.activation.execPolicy=none");
>> 51:         rmidLauncher.addToolArg("-J--add-modules=jdk.hotspot.agent");
>
> Is this really needed? Although SA will be using rmid, I don't understand why rmid needs to know about SA.

They are needed.

If we don't give `execPolicy=none`, we can see warning on console.
SA code would run on rmid, so we need to add module.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Chris Plummer-2
On Tue, 6 Apr 2021 00:56:08 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdRmidTest.java line 51:
>>
>>> 49:         JDKToolLauncher rmidLauncher = JDKToolLauncher.createUsingTestJDK("rmid");
>>> 50:         rmidLauncher.addToolArg("-J-Dsun.rmi.activation.execPolicy=none");
>>> 51:         rmidLauncher.addToolArg("-J--add-modules=jdk.hotspot.agent");
>>
>> Is this really needed? Although SA will be using rmid, I don't understand why rmid needs to know about SA.
>
> They are needed.
>
> If we don't give `execPolicy=none`, we can see warning on console.
> SA code would run on rmid, so we need to add module.

I was actually just referring to `--add-modules`, but github added a few lines before the one I selected.

I guess I'm not fully understanding what `rmid` is for in this context, and how it relates to the `rmiregistry` command. I thought it was starting the registry, but that does not seem to be it's primary purpose (maybe it starts it as a side affect). Also, it is deprecated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Yasumasa Suenaga-7
On Tue, 6 Apr 2021 01:42:45 GMT, Chris Plummer <[hidden email]> wrote:

>> They are needed.
>>
>> If we don't give `execPolicy=none`, we can see warning on console.
>> SA code would run on rmid, so we need to add module.
>
> I was actually just referring to `--add-modules`, but github added a few lines before the one I selected.
>
> I guess I'm not fully understanding what `rmid` is for in this context, and how it relates to the `rmiregistry` command. I thought it was starting the registry, but that does not seem to be it's primary purpose (maybe it starts it as a side affect). Also, it is deprecated.

SA has RMI remote object, it will be handled in RMI registry.
We can see following exception without `--add-modules`.

$ jhsdb debugd --pid 40339 --disableregistry --hostname localhost --registryport 1098
Attaching to process ID 40339 and starting RMI services, please wait...
Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
        java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
        at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:75)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:380)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:330)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:216)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runDEBUGD(SALauncher.java:437)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:499)
Caused by: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
        java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
        at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:389)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
        at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:831)
        at java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:303)
        at java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:279)
        at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:380)
        at java.rmi/sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:158)
        at java.rmi/java.rmi.Naming.rebind(Naming.java:177)
        at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:64)
        ... 5 more
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
        java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
        at java.rmi/sun.rmi.registry.RegistryImpl_Skel.dispatch(RegistryImpl_Skel.java:157)
        at java.rmi/sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:466)
        at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:296)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
        at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
        at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:432)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:586)
        at java.rmi/sun.rmi.server.LoaderHandler$Loader.loadClass(LoaderHandler.java:1207)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:466)
        at java.rmi/sun.rmi.server.LoaderHandler.loadClassForName(LoaderHandler.java:1221)
        at java.rmi/sun.rmi.server.LoaderHandler.loadProxyInterfaces(LoaderHandler.java:731)
        at java.rmi/sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:674)
        at java.rmi/sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:611)
        at java.rmi/java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:646)
        at java.rmi/java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:311)
        at java.rmi/sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:254)
        at java.base/java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1944)
        at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1886)
        at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
        at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1706)
        at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:496)
        at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:454)
        at java.rmi/sun.rmi.registry.RegistryImpl_Skel.dispatch(RegistryImpl_Skel.java:154)
        ... 14 more

As an option, we can also use RMI registry which is started by debugd as following:

* console 1
    * `jhsdb debugd --disableregistry --pid 40859`
* console 2
    * `jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=second debugd --disableregistry --pid 40860`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Chris Plummer-2
On Tue, 6 Apr 2021 02:46:40 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> I was actually just referring to `--add-modules`, but github added a few lines before the one I selected.
>>
>> I guess I'm not fully understanding what `rmid` is for in this context, and how it relates to the `rmiregistry` command. I thought it was starting the registry, but that does not seem to be it's primary purpose (maybe it starts it as a side affect). Also, it is deprecated.
>
> SA has RMI remote object, it will be handled in RMI registry.
> We can see following exception without `--add-modules`.
>
> $ jhsdb debugd --pid 40339 --disableregistry --hostname localhost --registryport 1098
> Attaching to process ID 40339 and starting RMI services, please wait...
> Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
>         java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
>         java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:75)
>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:380)
>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:330)
>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:216)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runDEBUGD(SALauncher.java:437)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:499)
> Caused by: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
>         java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
>         java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>         at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:389)
>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
>         at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
>         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
>         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>         at java.base/java.lang.Thread.run(Thread.java:831)
>         at java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:303)
>         at java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:279)
>         at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:380)
>         at java.rmi/sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:158)
>         at java.rmi/java.rmi.Naming.rebind(Naming.java:177)
>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:64)
>         ... 5 more
> Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
>         java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>         at java.rmi/sun.rmi.registry.RegistryImpl_Skel.dispatch(RegistryImpl_Skel.java:157)
>         at java.rmi/sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:466)
>         at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:296)
>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
>         at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
>         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
>         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>         at java.base/java.lang.Thread.run(Thread.java:831)
> Caused by: java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>         at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:432)
>         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:586)
>         at java.rmi/sun.rmi.server.LoaderHandler$Loader.loadClass(LoaderHandler.java:1207)
>         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>         at java.base/java.lang.Class.forName0(Native Method)
>         at java.base/java.lang.Class.forName(Class.java:466)
>         at java.rmi/sun.rmi.server.LoaderHandler.loadClassForName(LoaderHandler.java:1221)
>         at java.rmi/sun.rmi.server.LoaderHandler.loadProxyInterfaces(LoaderHandler.java:731)
>         at java.rmi/sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:674)
>         at java.rmi/sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:611)
>         at java.rmi/java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:646)
>         at java.rmi/java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:311)
>         at java.rmi/sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:254)
>         at java.base/java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1944)
>         at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1886)
>         at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
>         at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1706)
>         at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:496)
>         at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:454)
>         at java.rmi/sun.rmi.registry.RegistryImpl_Skel.dispatch(RegistryImpl_Skel.java:154)
>         ... 14 more
>
> As an option, we can also use RMI registry which is started by debugd as following:
>
> * console 1
>     * `jhsdb debugd --disableregistry --pid 40859`
> * console 2
>     * `jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=second debugd --disableregistry --pid 40860`

Both of the above are using `--disableregistry`. Is that what you meant to do? I would think that you would not want that on the first one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Yasumasa Suenaga-7
On Tue, 6 Apr 2021 03:16:29 GMT, Chris Plummer <[hidden email]> wrote:

>> SA has RMI remote object, it will be handled in RMI registry.
>> We can see following exception without `--add-modules`.
>>
>> $ jhsdb debugd --pid 40339 --disableregistry --hostname localhost --registryport 1098
>> Attaching to process ID 40339 and starting RMI services, please wait...
>> Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
>>         java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
>>         java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:75)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:380)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:330)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:216)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runDEBUGD(SALauncher.java:437)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:499)
>> Caused by: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
>>         java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
>>         java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>>         at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:389)
>>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
>>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
>>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
>>         at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
>>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
>>         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
>>         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>>         at java.base/java.lang.Thread.run(Thread.java:831)
>>         at java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:303)
>>         at java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:279)
>>         at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:380)
>>         at java.rmi/sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:158)
>>         at java.rmi/java.rmi.Naming.rebind(Naming.java:177)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:64)
>>         ... 5 more
>> Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
>>         java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>>         at java.rmi/sun.rmi.registry.RegistryImpl_Skel.dispatch(RegistryImpl_Skel.java:157)
>>         at java.rmi/sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:466)
>>         at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:296)
>>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
>>         at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
>>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
>>         at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
>>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
>>         at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
>>         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
>>         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>>         at java.base/java.lang.Thread.run(Thread.java:831)
>> Caused by: java.lang.ClassNotFoundException: sun.jvm.hotspot.debugger.remote.RemoteDebugger
>>         at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:432)
>>         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:586)
>>         at java.rmi/sun.rmi.server.LoaderHandler$Loader.loadClass(LoaderHandler.java:1207)
>>         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>>         at java.base/java.lang.Class.forName0(Native Method)
>>         at java.base/java.lang.Class.forName(Class.java:466)
>>         at java.rmi/sun.rmi.server.LoaderHandler.loadClassForName(LoaderHandler.java:1221)
>>         at java.rmi/sun.rmi.server.LoaderHandler.loadProxyInterfaces(LoaderHandler.java:731)
>>         at java.rmi/sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:674)
>>         at java.rmi/sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:611)
>>         at java.rmi/java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:646)
>>         at java.rmi/java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:311)
>>         at java.rmi/sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:254)
>>         at java.base/java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1944)
>>         at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1886)
>>         at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
>>         at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1706)
>>         at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:496)
>>         at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:454)
>>         at java.rmi/sun.rmi.registry.RegistryImpl_Skel.dispatch(RegistryImpl_Skel.java:154)
>>         ... 14 more
>>
>> As an option, we can also use RMI registry which is started by debugd as following:
>>
>> * console 1
>>     * `jhsdb debugd --disableregistry --pid 40859`
>> * console 2
>>     * `jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=second debugd --disableregistry --pid 40860`
>
> Both of the above are using `--disableregistry`. Is that what you meant to do? I would think that you would not want that on the first one.

Sorry, the correct commands are as follows:

* console 1 (start RMI registry)
    * `jhsdb debugd --pid 40859`
* console 2 (add `--disableregistry` to use it in console 1)
    * `jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=second debugd --disableregistry --pid 40860`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Chris Plummer-2
On Tue, 6 Apr 2021 03:32:25 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> Both of the above are using `--disableregistry`. Is that what you meant to do? I would think that you would not want that on the first one.
>
> Sorry, the correct commands are as follows:
>
> * console 1 (start RMI registry)
>     * `jhsdb debugd --pid 40859`
> * console 2 (add `--disableregistry` to use it in console 1)
>     * `jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=second debugd --disableregistry --pid 40860`

Is this the actual use case you are trying to address (registry already started by a debugd process). If yes, then I think that's the best approach for the test. If no, what is the use case? If it's some random application starting the registry, will there be issue related to it not having been started with `--add-modules=jdk.hotspot.agent`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v4]

Yasumasa Suenaga-7
In reply to this post by Yasumasa Suenaga-7
> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>
> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcase

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3233/files
  - new: https://git.openjdk.java.net/jdk/pull/3233/files/93c6f13e..adadf240

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=02-03

  Stats: 237 lines in 3 files changed: 123 ins; 114 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3233/head:pull/3233

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Yasumasa Suenaga-7
In reply to this post by Chris Plummer-2
On Tue, 6 Apr 2021 04:08:51 GMT, Chris Plummer <[hidden email]> wrote:

>> Sorry, the correct commands are as follows:
>>
>> * console 1 (start RMI registry)
>>     * `jhsdb debugd --pid 40859`
>> * console 2 (add `--disableregistry` to use it in console 1)
>>     * `jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=second debugd --disableregistry --pid 40860`
>
> Is this the actual use case you are trying to address (registry already started by a debugd process). If yes, then I think that's the best approach for the test. If no, what is the use case? If it's some random application starting the registry, will there be issue related to it not having been started with `--add-modules=jdk.hotspot.agent`?

I updated testcase. Could you review again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v4]

Chris Plummer-2
In reply to this post by Yasumasa Suenaga-7
On Tue, 6 Apr 2021 07:30:59 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>>
>> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>
>   Update testcase

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disableregistry option to jhsdb debugd [v2]

Chris Plummer-2
In reply to this post by Yasumasa Suenaga-7
On Tue, 6 Apr 2021 07:27:14 GMT, Yasumasa Suenaga <[hidden email]> wrote:

>> Is this the actual use case you are trying to address (registry already started by a debugd process). If yes, then I think that's the best approach for the test. If no, what is the use case? If it's some random application starting the registry, will there be issue related to it not having been started with `--add-modules=jdk.hotspot.agent`?
>
> I updated testcase. Could you review again?

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disable-registry option to jhsdb debugd [v5]

Yasumasa Suenaga-7
In reply to this post by Yasumasa Suenaga-7
> `jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>
> This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Rename --disableregistry to --disable-registry

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3233/files
  - new: https://git.openjdk.java.net/jdk/pull/3233/files/adadf240..87d3639a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=03-04

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3233/head:pull/3233

PR: https://git.openjdk.java.net/jdk/pull/3233
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8263636: Add --disable-registry option to jhsdb debugd [v4]

Yasumasa Suenaga-7
In reply to this post by Chris Plummer-2
On Tue, 6 Apr 2021 19:56:53 GMT, Chris Plummer <[hidden email]> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   Update testcase
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks @plummercj for the review!
I updated PR to rename `--disableregistry` to `--disable-registry` which is suggested in CSR.

I will finalize CSR when it is reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3233
12