Re: RFR:8207048: jhsdb debugd cannot specify a port number
Hi David and all, My goal is we can set the port of RMI and RMI registry through command line option in jhsdb debugd. So I want to create a CSR request of JDK-8207048 which propose to change jhsdb command line option. P.S.: I have never created a CSR request before. I'll need some time to learn that. Thanks, Yuji 2018-07-12 10:40 GMT+09:00 KUBOTA Yuji : > Hi David, > > Thank you for comment and updating JBS. I'll create a CSR request > after getting comments whether this change is welcomed by community. > > Thanks, > Yuji > > 2018-07-12 10:21 GMT+09:00 David Holmes : >> Hi Yuji, >> >> I can't comment on the actual change proposed in this enhancement request, >> but it will need to have a CSR request created and approved due to the use >> of a new system property. >> >> Thanks, >> David >> >> >> >> >> On 11/07/2018 11:55 PM, KUBOTA Yuji wrote: >>> >>> Hi all, >>> >>> I filed bugzilla for small fix to improvement of `jhsdb debugd` to set >>> a port of UnicastRemoteObject aka >>> sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer by >>> `sun.jvm.hotspot.rmi.debugger.port`. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207048 >>> Webrev: http://cr.openjdk.java.net/~ykubota/8207048/webrev.00/ >>> >>> We can set an RMI registry port of debugd server by >>> `sun.jvm.hotspot.rmi.port`, but can not set a port of RemoteObject. So >>> RemoteObject always uses an anonymous port. For security, we should >>> not open ports widely to use debugd, so I want to fix. >>> >>> Could you review it? >>> >>> Thanks, >>> Yuji >>> >>
Re: RFR:8207048: jhsdb debugd cannot specify a port number
Hi David, Thank you for comment and updating JBS. I'll create a CSR request after getting comments whether this change is welcomed by community. Thanks, Yuji 2018-07-12 10:21 GMT+09:00 David Holmes : > Hi Yuji, > > I can't comment on the actual change proposed in this enhancement request, > but it will need to have a CSR request created and approved due to the use > of a new system property. > > Thanks, > David > > > > > On 11/07/2018 11:55 PM, KUBOTA Yuji wrote: >> >> Hi all, >> >> I filed bugzilla for small fix to improvement of `jhsdb debugd` to set >> a port of UnicastRemoteObject aka >> sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer by >> `sun.jvm.hotspot.rmi.debugger.port`. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207048 >> Webrev: http://cr.openjdk.java.net/~ykubota/8207048/webrev.00/ >> >> We can set an RMI registry port of debugd server by >> `sun.jvm.hotspot.rmi.port`, but can not set a port of RemoteObject. So >> RemoteObject always uses an anonymous port. For security, we should >> not open ports widely to use debugd, so I want to fix. >> >> Could you review it? >> >> Thanks, >> Yuji >> >
RFR:8207048: jhsdb debugd cannot specify a port number
Hi all, I filed bugzilla for small fix to improvement of `jhsdb debugd` to set a port of UnicastRemoteObject aka sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer by `sun.jvm.hotspot.rmi.debugger.port`. Issue: https://bugs.openjdk.java.net/browse/JDK-8207048 Webrev: http://cr.openjdk.java.net/~ykubota/8207048/webrev.00/ We can set an RMI registry port of debugd server by `sun.jvm.hotspot.rmi.port`, but can not set a port of RemoteObject. So RemoteObject always uses an anonymous port. For security, we should not open ports widely to use debugd, so I want to fix. Could you review it? Thanks, Yuji
Re: Serviceability Agent tools / API usage .
Hi Arvind, May I ask what Serviceability Agent tools / API (which you want to survey) means? I think that it includes jdb, jinfo, jmap, jstack and Dynamic Attach. If this is right, my answers are below. 2016-06-29 1:15 GMT+09:00 Arvind Aprameya : > · Have you been using Serviceability Agent related API's or tools > for any of your debugging or analysis purpose (e.g. core dump / heapdump ) ? Yes. Exactly. I believe SA is great treasure! > · If the answer for the above question was yes, a very brief > explanation of what area's in your project have you been using ? I'm one of OpenJDK technical support engineers in Japan. I used hard these tools for troubleshooting many times. For example of corner case, I wrote a reproducer of jvm networking bug by using jdb. https://bugs.openjdk.java.net/browse/JDK-8151212 (reproducer-raw.txt) http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/testProgram/src/main/java/debugcontrol/DebugController.java#l114 In addition, Yasumasa and I developed HeapStats [1] which aims to improve after-the-fact analysis by using JVM TI agent for collecting java runtime information. HeapStats uses socket to AttachListener to get thread dump. [1]: http://icedtea.classpath.org/wiki/HeapStats/ > · Do you believe the current capabilities of SA are helpful / > important ? Exactly. > · Areas of improvement you would like to see / make in future ? By jdk9, we will use jcmd / jhsdb instead of jstack / jmap. I think it's a right way. I want to contribute serviceability groups as possible as before. > Please share your responses as replies to this thread on the > serviceability-dev list or to me directly until 12th July 2016. > > Thanks for your time in advance . > > > > thanks & regards, > > Arvind Thanks, Yuji
Re: Check core dumping is enabled when set CrashOnOutOfMemoryError
Thank David for taking time. And sorry for misunderstand about the purpose of each VM options. 2016-03-15 9:38 GMT+09:00 David Holmes : > Again clarify what you mean by this? Given CreateCoredumpOnCrash is usually > on this would produce warning messages in many execution contexts where core > dumps are disable (ie ulimit -c 0). That would be a bad thing. I aimed to notify warn before being faced with a crash if we run JVM on the execution context where core dumps are disabled (e.g. ulimit -c 0 by default) by something carelessness. I received many hs_err files which include the warm "Core dumps have been disabled." from users, so I want a notice to prevent it. Because hs_err includes useful information for after-the-fact analysis, but sometimes we need core image to reach the cause of crash, e.g., confirming the value of specified internal variables / structures. Thank you again for the detailed, I understood that my proposals are not reasonable. I have no good reasonable alternative ideas now, so withdraw this. Thanks, Yuji 2016-03-15 9:38 GMT+09:00 David Holmes : > On 14/03/2016 6:16 PM, KUBOTA Yuji wrote: >> >> Hi David, >> >> Sorry, please let discussion a bit more. >> >> 2016-03-14 9:25 GMT+09:00 David Holmes : >>> >>> First I'm not convinced that you necessarily want to enable core dumps >>> just >>> because you want to crash on OOM. >>> >>> Second I think anyone setting CrashOnOutOfMemoryError can easily remember >>> to >>> set CreateCoredumpOnCrash if they want it. >> >> >> I think most users do not pay attention about core dumping because >> * CreateCoredumpOnCrash is enabled by default (jdk9/hs-rt). >> * Core images not necessarily needed (except crash). >> So we should warn if core dumping is disabled and >> CreateCoredumpOnCrash is enabled, but continue to launch jvm. > > > What do you mean by "core dumping is disabled"? What is it you expect to be > checked? > > CreateCoredumpOnCrash (formerly CreateMinidumpOnCrash) was primarily a > windows flag to disable mini-dumps by default on Windows client builds. > Otherwise we expect the VM to always produce a core dump on crash. > >> However, the user who set CrashOnOutOfMemoryError need core images >> clearly, so I think jvm should return error if core dumping is >> disabled. > > > I disagree. The user who sets CrashOnOutOfMemoryError may also be setting > ShowMessageBoxOnError so they can attach a debugger or run other tools. > > The user who wants a core dump can enable core dumps explicitly if needed. > >> For example, I want to use CrashOnOOME instead of HeapDumpOnOOME, >> because we can exit jvm definitely and get heapdump and other helpful >> information by serviceability tools. >> >> In conclusion, I have two proposals for avoiding the lack of information. >> 1. Launch jvm with warn message if CreateCoredumpOnCrash is enabled >> but core dumping is disabled. > > > Again clarify what you mean by this? Given CreateCoredumpOnCrash is usually > on this would produce warning messages in many execution contexts where core > dumps are disable (ie ulimit -c 0). That would be a bad thing. > >> 2. 1 + Quit with error message if CrashOnOutOfMemoryError is enabled >> but core dumping is disabled. >> I think I should implement 2 in arguments.cpp. >> >> Could you share me your thought? > > > I don't agree that anything needs to be modified here - sorry. > > Thanks, > David > - > > > >> 2016-03-14 14:59 GMT+09:00 KUBOTA Yuji : >>> >>> Thanks David for looking and comments, >>> >>> 2016-03-14 9:25 GMT+09:00 David Holmes : >>>> >>>> First I'm not convinced that you necessarily want to enable core dumps >>>> just >>>> because you want to crash on OOM. >>> >>> >>> Yes, that's right. I just want to avoid the failed of core dumping >>> when we want it clearly by setting options. >>> >>>> Second I think anyone setting CrashOnOutOfMemoryError can easily >>>> remember to >>>> set CreateCoredumpOnCrash if they want it. >>>> >>>> Third if I was going to force this on then I would do it directly in >>>> arguments.cpp, not by adding a constraint function. >>> >>> >>> Thanks for sharing information! I will check the implementation of >>> CreateCoredumpOnCrash and update my patch to use arguments.cpp. >>> >>> Thanks, >>> Yuji >>> >>>> >>>> T
Re: Check core dumping is enabled when set CrashOnOutOfMemoryError
Hi David,
Sorry, please let discussion a bit more.
2016-03-14 9:25 GMT+09:00 David Holmes :
> First I'm not convinced that you necessarily want to enable core dumps just
> because you want to crash on OOM.
>
> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
> set CreateCoredumpOnCrash if they want it.
I think most users do not pay attention about core dumping because
* CreateCoredumpOnCrash is enabled by default (jdk9/hs-rt).
* Core images not necessarily needed (except crash).
So we should warn if core dumping is disabled and
CreateCoredumpOnCrash is enabled, but continue to launch jvm.
However, the user who set CrashOnOutOfMemoryError need core images
clearly, so I think jvm should return error if core dumping is
disabled.
For example, I want to use CrashOnOOME instead of HeapDumpOnOOME,
because we can exit jvm definitely and get heapdump and other helpful
information by serviceability tools.
In conclusion, I have two proposals for avoiding the lack of information.
1. Launch jvm with warn message if CreateCoredumpOnCrash is enabled
but core dumping is disabled.
2. 1 + Quit with error message if CrashOnOutOfMemoryError is enabled
but core dumping is disabled.
I think I should implement 2 in arguments.cpp.
Could you share me your thought?
2016-03-14 14:59 GMT+09:00 KUBOTA Yuji :
> Thanks David for looking and comments,
>
> 2016-03-14 9:25 GMT+09:00 David Holmes :
>> First I'm not convinced that you necessarily want to enable core dumps just
>> because you want to crash on OOM.
>
> Yes, that's right. I just want to avoid the failed of core dumping
> when we want it clearly by setting options.
>
>> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
>> set CreateCoredumpOnCrash if they want it.
>>
>> Third if I was going to force this on then I would do it directly in
>> arguments.cpp, not by adding a constraint function.
>
> Thanks for sharing information! I will check the implementation of
> CreateCoredumpOnCrash and update my patch to use arguments.cpp.
>
> Thanks,
> Yuji
>
>>
>> Thanks,
>> David
>> -
>>
>>
>>> So I create a patch to check the core dumping, please review it.
>>> I do not have an account of openjdk, so I need sponsor.
>>>
>>> I send to serviceability-dev because JDK-8138745 [1] has been
>>> reviewed here. If unfit, please let me know.
>>>
>>> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>>> https://bugs.openjdk.java.net/browse/JDK-8138745
>>>
>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> @@ -119,6 +119,17 @@
>>> }
>>> }
>>>
>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
>>> + char buffer[O_BUFLEN];
>>> + os::check_dump_limit(buffer, sizeof(buffer));
>>> + if (!VMError::coredump_status) {
>>> +CommandLineError::print(verbose,
>>> +"%s\n", VMError::coredump_message);
>>> +return Flag::VIOLATES_CONSTRAINT;
>>> + }
>>> + return Flag::SUCCESS;
>>> +}
>>> +
>>> Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>>> if ((value % PeriodicTask::interval_gran != 0)) {
>>> CommandLineError::print(verbose,
>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> @@ -43,6 +43,8 @@
>>> Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool
>>> verbose);
>>> Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>>>
>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
>>> +
>>> Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>>>
>>> #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
>>> diff --git a/src/share/vm/runtime/globals.hpp
>>> b/src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp
>>> +++ b/src/share/vm/runtime/globals.hpp
>>> @@ -1401,6 +1401,7 @@
>>> product(bool, CrashOnOutOfMemoryError, false,
>>> \
>>>
Re: Check core dumping is enabled when set CrashOnOutOfMemoryError
Thanks David for looking and comments,
2016-03-14 9:25 GMT+09:00 David Holmes :
> First I'm not convinced that you necessarily want to enable core dumps just
> because you want to crash on OOM.
Yes, that's right. I just want to avoid the failed of core dumping
when we want it clearly by setting options.
> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
> set CreateCoredumpOnCrash if they want it.
>
> Third if I was going to force this on then I would do it directly in
> arguments.cpp, not by adding a constraint function.
Thanks for sharing information! I will check the implementation of
CreateCoredumpOnCrash and update my patch to use arguments.cpp.
Thanks,
Yuji
>
> Thanks,
> David
> -
>
>
>> So I create a patch to check the core dumping, please review it.
>> I do not have an account of openjdk, so I need sponsor.
>>
>> I send to serviceability-dev because JDK-8138745 [1] has been
>> reviewed here. If unfit, please let me know.
>>
>> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>> https://bugs.openjdk.java.net/browse/JDK-8138745
>>
>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> @@ -119,6 +119,17 @@
>> }
>> }
>>
>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
>> + char buffer[O_BUFLEN];
>> + os::check_dump_limit(buffer, sizeof(buffer));
>> + if (!VMError::coredump_status) {
>> +CommandLineError::print(verbose,
>> +"%s\n", VMError::coredump_message);
>> +return Flag::VIOLATES_CONSTRAINT;
>> + }
>> + return Flag::SUCCESS;
>> +}
>> +
>> Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>> if ((value % PeriodicTask::interval_gran != 0)) {
>> CommandLineError::print(verbose,
>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> @@ -43,6 +43,8 @@
>> Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool
>> verbose);
>> Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>>
>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
>> +
>> Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>>
>> #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
>> diff --git a/src/share/vm/runtime/globals.hpp
>> b/src/share/vm/runtime/globals.hpp
>> --- a/src/share/vm/runtime/globals.hpp
>> +++ b/src/share/vm/runtime/globals.hpp
>> @@ -1401,6 +1401,7 @@
>> product(bool, CrashOnOutOfMemoryError, false,
>> \
>> "JVM aborts, producing an error log and core/mini dump, on the
>> " \
>> "first occurrence of an out-of-memory error")
>> \
>> + constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)
>> \
>>
>> \
>> /* tracing */
>> \
>>
>> \
>> diff --git a/src/share/vm/utilities/vmError.hpp
>> b/src/share/vm/utilities/vmError.hpp
>> --- a/src/share/vm/utilities/vmError.hpp
>> +++ b/src/share/vm/utilities/vmError.hpp
>> @@ -65,14 +65,6 @@
>> // so use thread id instead of Thread* to identify thread.
>> static volatile intptr_t first_error_tid;
>>
>> - // Core dump status, false if we have been unable to write a
>> core/minidump for some reason
>> - static bool coredump_status;
>> -
>> - // When coredump_status is set to true this will contain the
>> name/path to the core/minidump,
>> - // if coredump_status if false, this will (hopefully) contain a
>> useful error explaining why
>> - // no core/minidump has been written to disk
>> - static char coredump_message[O_BUFLEN];
>> -
>>
>> // set signal handlers on Solaris/Linux or the default exception
>> filter
>> // on Windows, to handle recursive crashes.
>> @@ -111,6 +103,14 @@
>> // Record status of core/minidump
>> static void record_coredump_status(const char* message, bool status);
>>
>> + // Core dump status, false if we have been unable to write a
>> core/minidump for some reason
>> + static bool coredump_status;
>> +
>> + // When coredump_status is set to true this will contain the
>> name/path to the core/minidump,
>> + // if coredump_status if false, this will (hopefully) contain a
>> useful error explaining why
>> + // no core/minidump has been written to disk
>> + static char coredump_message[O_BUFLEN];
>> +
>> // support for VM.info diagnostic command
>> static void print_vm_info(outputStream* st);
>>
>>
>> Thanks,
>> Yuji
>>
>
Check core dumping is enabled when set CrashOnOutOfMemoryError
Hi everyone.
When set -XX:+CrashOnOutOfMemoryError, I think we should know
whether core dumping has been enabled or not before launching
process to prevent lack of information for after-the-fact analysis.
So I create a patch to check the core dumping, please review it.
I do not have an account of openjdk, so I need sponsor.
I send to serviceability-dev because JDK-8138745 [1] has been
reviewed here. If unfit, please let me know.
[1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
https://bugs.openjdk.java.net/browse/JDK-8138745
diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
--- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
+++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
@@ -119,6 +119,17 @@
}
}
+Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
+ char buffer[O_BUFLEN];
+ os::check_dump_limit(buffer, sizeof(buffer));
+ if (!VMError::coredump_status) {
+CommandLineError::print(verbose,
+"%s\n", VMError::coredump_message);
+return Flag::VIOLATES_CONSTRAINT;
+ }
+ return Flag::SUCCESS;
+}
+
Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
if ((value % PeriodicTask::interval_gran != 0)) {
CommandLineError::print(verbose,
diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
--- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
+++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
@@ -43,6 +43,8 @@
Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool verbose);
Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
+Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
+
Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
#endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
diff --git a/src/share/vm/runtime/globals.hpp b/src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp
+++ b/src/share/vm/runtime/globals.hpp
@@ -1401,6 +1401,7 @@
product(bool, CrashOnOutOfMemoryError, false, \
"JVM aborts, producing an error log and core/mini dump, on the " \
"first occurrence of an out-of-memory error") \
+ constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo) \
\
/* tracing */ \
\
diff --git a/src/share/vm/utilities/vmError.hpp
b/src/share/vm/utilities/vmError.hpp
--- a/src/share/vm/utilities/vmError.hpp
+++ b/src/share/vm/utilities/vmError.hpp
@@ -65,14 +65,6 @@
// so use thread id instead of Thread* to identify thread.
static volatile intptr_t first_error_tid;
- // Core dump status, false if we have been unable to write a
core/minidump for some reason
- static bool coredump_status;
-
- // When coredump_status is set to true this will contain the
name/path to the core/minidump,
- // if coredump_status if false, this will (hopefully) contain a
useful error explaining why
- // no core/minidump has been written to disk
- static char coredump_message[O_BUFLEN];
-
// set signal handlers on Solaris/Linux or the default exception filter
// on Windows, to handle recursive crashes.
@@ -111,6 +103,14 @@
// Record status of core/minidump
static void record_coredump_status(const char* message, bool status);
+ // Core dump status, false if we have been unable to write a
core/minidump for some reason
+ static bool coredump_status;
+
+ // When coredump_status is set to true this will contain the
name/path to the core/minidump,
+ // if coredump_status if false, this will (hopefully) contain a
useful error explaining why
+ // no core/minidump has been written to disk
+ static char coredump_message[O_BUFLEN];
+
// support for VM.info diagnostic command
static void print_vm_info(outputStream* st);
Thanks,
Yuji
Re: PING: Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable
Dmitry,
Thank you for your kindly sponsorship!
- Yuji
2016-03-07 20:48 GMT+09:00 Dmitry Samersoff :
> Yuji,
>
> CR number is JDK-8151368
>
> -Dmitry
>
> On 2016-02-22 15:31, KUBOTA Yuji wrote:
>> Hi all,
>>
>> Could you please review this patch?
>> I do not have any account at openjdk now, so I need a sponsor.
>>
>> Thanks,
>> Yuji
>>
>> 2015-12-18 15:27 GMT+09:00 KUBOTA Yuji :
>>> Hi all,
>>>
>>> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
>>> jhsdb as below.
>>>
>>> -
>>> ./jhsdb clhsdb --pid 16809
>>> Attaching to process 16809, please wait...
>>> hsdb> class java/lang/ArithmeticException
>>> java/lang/ArithmeticException @0x000100011958
>>> hsdb> class java
>>> class not found: java
>>> hsdb> class java/lang
>>> Error: java.lang.ArithmeticException: / by zero
>>> -
>>>
>>> I think that CLHSDB returns "class not found: java/lang". But
>>> ArithmetricException is returned instead.
>>> CLHSDB tries to search the given class name from the regular symbol
>>> table and the shared symbol table.
>>> And called the probe function of the shared symbol table does not
>>> support a case of the empty bucket such as below expression
>>>
>>>> long index = hash % bucketCount();
>>>
>>> then, throws ArithmetricException.
>>>
>>> The stack trace of this java.lang.ArithmeticException is here.
>>> --
>>> java.lang.ArithmeticException: / by zero
>>> at
>>> sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
>>> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
>>> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
>>> at
>>> sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
>>> at
>>> sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
>>> at
>>> jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
>>> at
>>> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
>>> at
>>> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
>>> at
>>> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
>>> at
>>> jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
>>> at
>>> jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
>>> at
>>> jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
>>> at
>>> sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
>>> at
>>> sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
>>> at
>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
>>> at
>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
>>> at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
>>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
>>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
>>> at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
>>> --
>>>
>>> I have created a patch from jdk9/dev/hotspot (changeset:
>>> 9625:de592ea5f7ba) as below, and checked to return "class not found
>>> java/lang" correctly. Please review it.
>>>
>>> diff --git
>>> a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> ---
>>> a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> +++
>>> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> @@ -86,6 +86,10 @@
>>> Address baseAddress = baseAddressField.getValue(addr);
>>> Address bucket = bucketsField.getValue(addr);
>>> Address bucketEnd = bucket;
>>> +
>>> +if (bucketCount() == 0) {
>>> + return null;
>>> +}
>>> long index = hash % bucketCount();
>>> int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
>>> uintSize, true);
>>> int bucketOffset = bucketOffset(bucketInfo);
>>>
>>>
>>> Thanks,
>>> Yuji
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
PING: Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable
Hi all,
Could you please review this patch?
I do not have any account at openjdk now, so I need a sponsor.
Thanks,
Yuji
2015-12-18 15:27 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
> jhsdb as below.
>
> -
> ./jhsdb clhsdb --pid 16809
> Attaching to process 16809, please wait...
> hsdb> class java/lang/ArithmeticException
> java/lang/ArithmeticException @0x000100011958
> hsdb> class java
> class not found: java
> hsdb> class java/lang
> Error: java.lang.ArithmeticException: / by zero
> -
>
> I think that CLHSDB returns "class not found: java/lang". But
> ArithmetricException is returned instead.
> CLHSDB tries to search the given class name from the regular symbol
> table and the shared symbol table.
> And called the probe function of the shared symbol table does not
> support a case of the empty bucket such as below expression
>
>> long index = hash % bucketCount();
>
> then, throws ArithmetricException.
>
> The stack trace of this java.lang.ArithmeticException is here.
> --
> java.lang.ArithmeticException: / by zero
> at
> sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
> at
> sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
> at
> sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
> at
> jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
> at
> sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
> at
> sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
> at
> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
> at
> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
> at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
> at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
> --
>
> I have created a patch from jdk9/dev/hotspot (changeset:
> 9625:de592ea5f7ba) as below, and checked to return "class not found
> java/lang" correctly. Please review it.
>
> diff --git
> a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> @@ -86,6 +86,10 @@
> Address baseAddress = baseAddressField.getValue(addr);
> Address bucket = bucketsField.getValue(addr);
> Address bucketEnd = bucket;
> +
> +if (bucketCount() == 0) {
> + return null;
> +}
> long index = hash % bucketCount();
> int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
> uintSize, true);
> int bucketOffset = bucketOffset(bucketInfo);
>
>
> Thanks,
> Yuji
PING: Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable
Hi all,
Could you please review this patch?
I do not have any account at openjdk now, so I need a sponsor.
Thanks,
Yuji
2015-12-18 15:27 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
> jhsdb as below.
>
> -
> ./jhsdb clhsdb --pid 16809
> Attaching to process 16809, please wait...
> hsdb> class java/lang/ArithmeticException
> java/lang/ArithmeticException @0x000100011958
> hsdb> class java
> class not found: java
> hsdb> class java/lang
> Error: java.lang.ArithmeticException: / by zero
> -
>
> I think that CLHSDB returns "class not found: java/lang". But
> ArithmetricException is returned instead.
> CLHSDB tries to search the given class name from the regular symbol
> table and the shared symbol table.
> And called the probe function of the shared symbol table does not
> support a case of the empty bucket such as below expression
>
>> long index = hash % bucketCount();
>
> then, throws ArithmetricException.
>
> The stack trace of this java.lang.ArithmeticException is here.
> --
> java.lang.ArithmeticException: / by zero
> at
> sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
> at
> sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
> at
> sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
> at
> jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
> at
> sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
> at
> sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
> at
> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
> at
> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
> at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
> at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
> --
>
> I have created a patch from jdk9/dev/hotspot (changeset:
> 9625:de592ea5f7ba) as below, and checked to return "class not found
> java/lang" correctly. Please review it.
>
> diff --git
> a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> @@ -86,6 +86,10 @@
> Address baseAddress = baseAddressField.getValue(addr);
> Address bucket = bucketsField.getValue(addr);
> Address bucketEnd = bucket;
> +
> +if (bucketCount() == 0) {
> + return null;
> +}
> long index = hash % bucketCount();
> int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
> uintSize, true);
> int bucketOffset = bucketOffset(bucketInfo);
>
>
> Thanks,
> Yuji
Re: RFR(XS): JDK-8149099 jcmd -help mention non-existent option
Hi Dmitry, Jaroslav Many thanks again for your sponsor and review! http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/fb55d8342279 Yuji 2016-02-05 22:27 GMT+09:00 Jaroslav Bachorik : > On 5.2.2016 11:53, Dmitry Samersoff wrote: >> >> Everybody, >> >> Please, review typo fix provided by Kubota Yuji >> >> >> http://cr.openjdk.java.net/~dsamersoff/sponsorship/kubota.yuji/JDK-8149099/webrev.01/ > > > Looks good! > > -JB- > >> >> -Dmitry >> >
[PING] Re: jcmd -help shows non-existent option
Hi all,
I do not have any role of openjdk projects. Could someone review & sponsor this?
This might help user, but be too trivial. If this patch is
inappropriate please let me know.
Thanks,
Yuji.
2016-01-04 17:41 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> It's just typo level. The jcmd help messages include non-existent
> option as below.
>
> If no options are given, lists Java processes (same as -p).
>
> I confirmed the jcmd implementation, but could not find "-p".
> I think "-l" is correct.
>
> I write a patch from jdk9/dev/jdk (13406:f9919c0e0a18).
> Please review it.
>
> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
> @@ -119,7 +119,7 @@
> System.out.println(" If the pid is 0, commands will be sent
> to all Java processes. ");
> System.out.println(" The main class argument will be used to
> match (either partially ");
> System.out.println(" or fully) the class used to start Java.
> ");
> -System.out.println(" If no options are given, lists Java
> processes (same as -p). ");
> +System.out.println(" If no options are given, lists Java
> processes (same as -l). ");
> System.out.println("
> ");
> System.out.println(" PerfCounter.print display the counters
> exposed by this process ");
> System.out.println(" -f read and execute commands from the
> file ");
> diff --git a/test/sun/tools/jcmd/usage.out b/test/sun/tools/jcmd/usage.out
> --- a/test/sun/tools/jcmd/usage.out
> +++ b/test/sun/tools/jcmd/usage.out
> @@ -7,7 +7,7 @@
>If the pid is 0, commands will be sent to all Java processes.
>The main class argument will be used to match (either partially
>or fully) the class used to start Java.
> - If no options are given, lists Java processes (same as -p).
> + If no options are given, lists Java processes (same as -l).
>
>PerfCounter.print display the counters exposed by this process
>-f read and execute commands from the file
>
> Thanks,
> Yuji
Re: RFR(S): JDK-8148104 HSDB could not terminate when launched on CLI.
2016-01-26 19:56 GMT+09:00 Jaroslav Bachorik :
> On 26.1.2016 11:54, Dmitry Samersoff wrote:
>>
>> Yuji,
>>
>> I think both changes are good so I add this patch to webrev.
>>
>> see:
>>
>>
>> http://cr.openjdk.java.net/~dsamersoff/sponsorship/kubota.yuji/JDK-8148104/webrev.02/
>
>
> Thanks Yuji, Dmitry!
>
> Thumbs up!
Thanks Dmitry, Jaroslav !
Do I need more reviewer?
>
> -JB-
>
>
>>
>> -Dmitry
>>
>>
>> On 2016-01-25 13:57, KUBOTA Yuji wrote:
>>>
>>> Hi Dmitry and Jaroslav,
>>>
>>> 2016-01-25 18:11 GMT+09:00 Jaroslav Bachorik
>>> :
>>>>
>>>> On 23.1.2016 12:13, Dmitry Samersoff wrote:
>>>>>
>>>>> Solution:
>>>>>
>>>>> Create frame before we initialize agent.
>>>>
>>>>
>>>>
>>>> While this solution will work in this case I think it would be better to
>>>> daemonize the WorkerThread
>>>>
>>>> (hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java)
>>>> - that should ensure that the application will be allowed to terminate
>>>> even
>>>> though the worker thread is still running.
>>>
>>>
>>> It's reasonable for me. I could not come up with the reason why the
>>> WorkerThread is not daemonized, so I wrote simply.
>>> I think that WorkerThread can be abandoned when JVM halts, so
>>> recreated the patch to demonize as below.
>>>
>>> jdk9/hs-rt/hotspot (9982:91be2fb6db87)
>>>
>>> diff --git
>>> a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
>>>
>>> b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
>>> ---
>>> a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
>>> +++
>>> b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
>>> @@ -35,7 +35,11 @@
>>> public WorkerThread() {
>>> mqb = new MessageQueueBackend();
>>> mq = mqb.getFirstQueue();
>>> -new Thread(new MainLoop()).start();
>>> +
>>> +// Enable to terminate this worker during runnning by daemonize.
>>> +Thread mqthread = new Thread(new MainLoop());
>>> +mqthread.setDaemon(true);
>>> +mqthread.start();
>>> }
>>>
>>> /** Runs the given Runnable in the thread represented by this
>>>
>>>
>>> Sorry, Dmitry, could you please re-upload this patch if you agree with
>>> this idea?
>>>
>>> Thanks,
>>> Yuji
>>>
>>>> -JB-
>>>>
>>>>>
>>>>> -Dmitry
>>
>>
>>
>
Re: RFR(S): JDK-8148104 HSDB could not terminate when launched on CLI.
Hi Dmitry and Jaroslav,
2016-01-25 18:11 GMT+09:00 Jaroslav Bachorik :
> On 23.1.2016 12:13, Dmitry Samersoff wrote:
>> Solution:
>>
>> Create frame before we initialize agent.
>
>
> While this solution will work in this case I think it would be better to
> daemonize the WorkerThread
> (hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java)
> - that should ensure that the application will be allowed to terminate even
> though the worker thread is still running.
It's reasonable for me. I could not come up with the reason why the
WorkerThread is not daemonized, so I wrote simply.
I think that WorkerThread can be abandoned when JVM halts, so
recreated the patch to demonize as below.
jdk9/hs-rt/hotspot (9982:91be2fb6db87)
diff --git
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
---
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
+++
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java
@@ -35,7 +35,11 @@
public WorkerThread() {
mqb = new MessageQueueBackend();
mq = mqb.getFirstQueue();
-new Thread(new MainLoop()).start();
+
+// Enable to terminate this worker during runnning by daemonize.
+Thread mqthread = new Thread(new MainLoop());
+mqthread.setDaemon(true);
+mqthread.start();
}
/** Runs the given Runnable in the thread represented by this
Sorry, Dmitry, could you please re-upload this patch if you agree with
this idea?
Thanks,
Yuji
> -JB-
>
>>
>> -Dmitry
Re: HSDB could not terminate when launched on CLI.
Dmitry
Thank you for your review!
Sorry, I do not have any role of OpenJDK yet. So I can't upload webrev.
I will send a request for becoming Author after pushing these patches :)
Thanks,
Yuji
2016-01-19 2:42 GMT+09:00 Dmitry Samersoff :
> Yuji
>
> Looks good for me.
>
> Are you a committer? If yes, please prepare a changeset. I'll sponsor
> the push.
>
> -Dmitry
>
> On 2015-12-15 11:23, KUBOTA Yuji wrote:
>> Hi all,
>>
>> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
>> not terminate after throwing HeadlessException.
>>
>> HSDB starts WorkerThread before making the JFrame. If we run HSDB on
>> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the
>> WorkerThread has never shutdown, then HSDB can not terminate.
>>
>> -
>> Exception in thread "main" java.awt.HeadlessException:
>> No X11 DISPLAY variable was set, but this program performed an
>> operation which requires it.
>> at
>> java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205)
>> at java.awt.Window.(Window.java:535)
>> at java.awt.Frame.(Frame.java:422)
>> at javax.swing.JFrame.(JFrame.java:224)
>> at sun.jvm.hotspot.HSDB.run(HSDB.java:140)
>> at sun.jvm.hotspot.HSDB.main(HSDB.java:53)
>> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167)
>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339)
>> ## Waiting for the shutdown of WorkerThread forever... ###
>> -
>>
>> I have created a patch from jdk9/dev/hotspot (changeset:
>> 9625:de592ea5f7ba) as below. Please review it !
>>
>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> @@ -137,15 +137,16 @@
>> return;
>> }
>>
>> +// Make frame at first, then initialize agent.
>> +frame = new JFrame("HSDB - HotSpot Debugger");
>> +frame.setSize(800, 600);
>> +frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>> +
>> agent = new HotSpotAgent();
>> workerThread = new WorkerThread();
>> attachMenuItems = new java.util.ArrayList();
>> detachMenuItems = new java.util.ArrayList();
>>
>> -frame = new JFrame("HSDB - HotSpot Debugger");
>> -frame.setSize(800, 600);
>> -frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>> -
>> JMenuBar menuBar = new JMenuBar();
>>
>> //
>>
>>
>> Thanks,
>> Yuji
>>
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
Re: HSDB could not terminate when launched on CLI.
Hi Dmitry,
Could you please review this patch and the below patch which are related JHSDB?
http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-January/018656.html
Thanks in advance,
Yuji
2016-01-06 3:08 GMT+09:00 Dmitry Samersoff :
> Yuji,
>
> I'm on vacation till Jan 10, answer you next week.
>
> Sorry!
> Dmitry.
>
>
> On 2016-01-05 18:01, KUBOTA Yuji wrote:
>> Hi Dmitry,
>>
>> Thank you for your time. If you have a comment, please let me know.
>>
>> Thanks,
>> Yuji
>>
>> 2015-12-15 18:11 GMT+09:00 Dmitry Samersoff :
>>> Yuji,
>>>
>>> I'll take a look.
>>>
>>> -Dmitry
>>>
>>> On 2015-12-15 11:23, KUBOTA Yuji wrote:
>>>> Hi all,
>>>>
>>>> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
>>>> not terminate after throwing HeadlessException.
>>>>
>>>> HSDB starts WorkerThread before making the JFrame. If we run HSDB on
>>>> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the
>>>> WorkerThread has never shutdown, then HSDB can not terminate.
>>>>
>>>> -
>>>> Exception in thread "main" java.awt.HeadlessException:
>>>> No X11 DISPLAY variable was set, but this program performed an
>>>> operation which requires it.
>>>> at
>>>> java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205)
>>>> at java.awt.Window.(Window.java:535)
>>>> at java.awt.Frame.(Frame.java:422)
>>>> at javax.swing.JFrame.(JFrame.java:224)
>>>> at sun.jvm.hotspot.HSDB.run(HSDB.java:140)
>>>> at sun.jvm.hotspot.HSDB.main(HSDB.java:53)
>>>> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167)
>>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339)
>>>> ## Waiting for the shutdown of WorkerThread forever... ###
>>>> -
>>>>
>>>> I have created a patch from jdk9/dev/hotspot (changeset:
>>>> 9625:de592ea5f7ba) as below. Please review it !
>>>>
>>>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> @@ -137,15 +137,16 @@
>>>> return;
>>>> }
>>>>
>>>> +// Make frame at first, then initialize agent.
>>>> +frame = new JFrame("HSDB - HotSpot Debugger");
>>>> +frame.setSize(800, 600);
>>>> +frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>>> +
>>>> agent = new HotSpotAgent();
>>>> workerThread = new WorkerThread();
>>>> attachMenuItems = new java.util.ArrayList();
>>>> detachMenuItems = new java.util.ArrayList();
>>>>
>>>> -frame = new JFrame("HSDB - HotSpot Debugger");
>>>> -frame.setSize(800, 600);
>>>> -frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>>> -
>>>> JMenuBar menuBar = new JMenuBar();
>>>>
>>>> //
>>>>
>>>>
>>>> Thanks,
>>>> Yuji
>>>>
>>>
>>>
>>> --
>>> Dmitry Samersoff
>>> Oracle Java development team, Saint Petersburg, Russia
>>> * I would love to change the world, but they won't give me the source code.
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
[PING]Re: Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable
Hi all,
Could you please review this patch?
Thanks,
Yuji
2015-12-18 15:27 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
> jhsdb as below.
>
> -
> ./jhsdb clhsdb --pid 16809
> Attaching to process 16809, please wait...
> hsdb> class java/lang/ArithmeticException
> java/lang/ArithmeticException @0x000100011958
> hsdb> class java
> class not found: java
> hsdb> class java/lang
> Error: java.lang.ArithmeticException: / by zero
> -
>
> I think that CLHSDB returns "class not found: java/lang". But
> ArithmetricException is returned instead.
> CLHSDB tries to search the given class name from the regular symbol
> table and the shared symbol table.
> And called the probe function of the shared symbol table does not
> support a case of the empty bucket such as below expression
>
>> long index = hash % bucketCount();
>
> then, throws ArithmetricException.
>
> The stack trace of this java.lang.ArithmeticException is here.
> --
> java.lang.ArithmeticException: / by zero
> at
> sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
> at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
> at
> sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
> at
> sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
> at
> jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
> at
> sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
> at
> sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
> at
> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
> at
> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
> at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
> at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
> --
>
> I have created a patch from jdk9/dev/hotspot (changeset:
> 9625:de592ea5f7ba) as below, and checked to return "class not found
> java/lang" correctly. Please review it.
>
> diff --git
> a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
> @@ -86,6 +86,10 @@
> Address baseAddress = baseAddressField.getValue(addr);
> Address bucket = bucketsField.getValue(addr);
> Address bucketEnd = bucket;
> +
> +if (bucketCount() == 0) {
> + return null;
> +}
> long index = hash % bucketCount();
> int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
> uintSize, true);
> int bucketOffset = bucketOffset(bucketInfo);
>
>
> Thanks,
> Yuji
Re: HSDB could not terminate when launched on CLI.
Dmitry,
Thank your reply on vacation. Have a good time :)
Thanks,
Yuji
2016-01-06 3:08 GMT+09:00 Dmitry Samersoff :
> Yuji,
>
> I'm on vacation till Jan 10, answer you next week.
>
> Sorry!
> Dmitry.
>
>
> On 2016-01-05 18:01, KUBOTA Yuji wrote:
>> Hi Dmitry,
>>
>> Thank you for your time. If you have a comment, please let me know.
>>
>> Thanks,
>> Yuji
>>
>> 2015-12-15 18:11 GMT+09:00 Dmitry Samersoff :
>>> Yuji,
>>>
>>> I'll take a look.
>>>
>>> -Dmitry
>>>
>>> On 2015-12-15 11:23, KUBOTA Yuji wrote:
>>>> Hi all,
>>>>
>>>> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
>>>> not terminate after throwing HeadlessException.
>>>>
>>>> HSDB starts WorkerThread before making the JFrame. If we run HSDB on
>>>> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the
>>>> WorkerThread has never shutdown, then HSDB can not terminate.
>>>>
>>>> -
>>>> Exception in thread "main" java.awt.HeadlessException:
>>>> No X11 DISPLAY variable was set, but this program performed an
>>>> operation which requires it.
>>>> at
>>>> java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205)
>>>> at java.awt.Window.(Window.java:535)
>>>> at java.awt.Frame.(Frame.java:422)
>>>> at javax.swing.JFrame.(JFrame.java:224)
>>>> at sun.jvm.hotspot.HSDB.run(HSDB.java:140)
>>>> at sun.jvm.hotspot.HSDB.main(HSDB.java:53)
>>>> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167)
>>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339)
>>>> ## Waiting for the shutdown of WorkerThread forever... ###
>>>> -
>>>>
>>>> I have created a patch from jdk9/dev/hotspot (changeset:
>>>> 9625:de592ea5f7ba) as below. Please review it !
>>>>
>>>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>>>> @@ -137,15 +137,16 @@
>>>> return;
>>>> }
>>>>
>>>> +// Make frame at first, then initialize agent.
>>>> +frame = new JFrame("HSDB - HotSpot Debugger");
>>>> +frame.setSize(800, 600);
>>>> +frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>>> +
>>>> agent = new HotSpotAgent();
>>>> workerThread = new WorkerThread();
>>>> attachMenuItems = new java.util.ArrayList();
>>>> detachMenuItems = new java.util.ArrayList();
>>>>
>>>> -frame = new JFrame("HSDB - HotSpot Debugger");
>>>> -frame.setSize(800, 600);
>>>> -frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>>> -
>>>> JMenuBar menuBar = new JMenuBar();
>>>>
>>>> //
>>>>
>>>>
>>>> Thanks,
>>>> Yuji
>>>>
>>>
>>>
>>> --
>>> Dmitry Samersoff
>>> Oracle Java development team, Saint Petersburg, Russia
>>> * I would love to change the world, but they won't give me the source code.
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
Re: HSDB could not terminate when launched on CLI.
Hi Dmitry,
Thank you for your time. If you have a comment, please let me know.
Thanks,
Yuji
2015-12-15 18:11 GMT+09:00 Dmitry Samersoff :
> Yuji,
>
> I'll take a look.
>
> -Dmitry
>
> On 2015-12-15 11:23, KUBOTA Yuji wrote:
>> Hi all,
>>
>> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
>> not terminate after throwing HeadlessException.
>>
>> HSDB starts WorkerThread before making the JFrame. If we run HSDB on
>> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the
>> WorkerThread has never shutdown, then HSDB can not terminate.
>>
>> -
>> Exception in thread "main" java.awt.HeadlessException:
>> No X11 DISPLAY variable was set, but this program performed an
>> operation which requires it.
>> at
>> java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205)
>> at java.awt.Window.(Window.java:535)
>> at java.awt.Frame.(Frame.java:422)
>> at javax.swing.JFrame.(JFrame.java:224)
>> at sun.jvm.hotspot.HSDB.run(HSDB.java:140)
>> at sun.jvm.hotspot.HSDB.main(HSDB.java:53)
>> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167)
>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339)
>> ## Waiting for the shutdown of WorkerThread forever... ###
>> -
>>
>> I have created a patch from jdk9/dev/hotspot (changeset:
>> 9625:de592ea5f7ba) as below. Please review it !
>>
>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
>> @@ -137,15 +137,16 @@
>> return;
>> }
>>
>> +// Make frame at first, then initialize agent.
>> +frame = new JFrame("HSDB - HotSpot Debugger");
>> +frame.setSize(800, 600);
>> +frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>> +
>> agent = new HotSpotAgent();
>> workerThread = new WorkerThread();
>> attachMenuItems = new java.util.ArrayList();
>> detachMenuItems = new java.util.ArrayList();
>>
>> -frame = new JFrame("HSDB - HotSpot Debugger");
>> -frame.setSize(800, 600);
>> -frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>> -
>> JMenuBar menuBar = new JMenuBar();
>>
>> //
>>
>>
>> Thanks,
>> Yuji
>>
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the source code.
[PING] Potential infinite waiting at JMXConnection#createConnection
Hi all,
Could you please review this patch?
Thanks,
Yuji
2015-12-17 2:05 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> If Shanliang cannot review, someone could review it?
>
> I reported this issue first at the below.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-May/017241.html
>
> Hope this patch helps to community.
>
> Thanks,
> Yuji
>
> 2015-12-10 22:40 GMT+09:00 KUBOTA Yuji :
>> Hi Shanliang and all,
>>
>> Sorry my reply is too late. But, finally, I reproduced this issue by
>> following test program! :)
>> Could you please review test program and my patch ?
>>
>> The test program includes some files, but I do not have an account of
>> openjdk, so I push it on icedtea server as below.
>>
>> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f
>>
>> The test program starts a simple sleep server program (JMXSSLServer)
>> on external jdb process with a breakpoint at
>> sun.security.ssl.ServerHandshaker.clientHello set. It then starts a
>> client process (JMXSSLCient) which tries to connect the sleep/jdb
>> process.
>> ServerHandshaker.clientHello responds to the client hello message and
>> sends SSL record back. By setting breakpont in that function, we can
>> emulate this issue in which client keeps waiting SSL record from
>> server.
>> Now, JMXConnectorFactory.connect() ignores
>> sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL
>> record) from server INFINITELY. Once my patch (jdk9.patch) was added,
>> then the client will return 0 when the connection timeout happen by
>> sun.rmi.transport.tcp.responseTimeout.
>> And test program returns the client's return code.
>>
>> You can reproduce infinite waiting by the below.
>> * hg clone
>> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/
>> * cd fixLoopAtJMXConnectorFactory/testProgram
>> * set JAVA_HOME
>> * mvn package
>> * setting debugcontrol.properties if you need.
>> * *NOTE* This test program will stop for "debugcontroltest.stop_time" ms.
>> * ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar
>> debugcontrol.DebugController
>>
>> * The result by JDK without my patch.
>> The client throws java.net.ConnectException after sending quit to jdb.
>> --
>> [INFO] Server process args
>> args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb
>> :
>> :
>> cli-out: [INFO] Service URL:
>> service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi
>> ser-err: Set deferred breakpoint
>> sun.security.ssl.ServerHandshaker.clientHello
>> ser-out:
>> ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1",
>> sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0
>> ser-out:
>> [INFO] sending quit to jdb
>> ser-err: RMI TCP Connection(2)-127.0.0.1[1]
>> cli-err: java.rmi.ConnectException: Connection refused to host:
>> 127.0.0.1; nested exception is:
>> cli-err:java.net.ConnectException: Connection refused
>> cli-err:at
>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>> cli-err:at
>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>> cli-err:at
>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>> cli-err:at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130)
>> cli-err:at
>> javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown
>> Source)
>> cli-err:at
>> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432)
>> cli-err:at
>> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308)
>> cli-err:at
>> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
>> cli-err:at
>> debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51)
>> cli-err:at
>> debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34)
>> cli-err: Caused by: java.net.ConnectException: Connection refused
>> cli-err:at java.net.PlainSocketImpl.socketConnect(Native Method)
>> cli-err:at
>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
>> cli-err:at
>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>> cli-err:at
>> java.net.AbstractPlainSocketImpl.connect(Abstra
jcmd -help shows non-existent option
Hi all,
It's just typo level. The jcmd help messages include non-existent
option as below.
If no options are given, lists Java processes (same as -p).
I confirmed the jcmd implementation, but could not find "-p".
I think "-l" is correct.
I write a patch from jdk9/dev/jdk (13406:f9919c0e0a18).
Please review it.
diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
b/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
--- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
+++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java
@@ -119,7 +119,7 @@
System.out.println(" If the pid is 0, commands will be sent
to all Java processes. ");
System.out.println(" The main class argument will be used to
match (either partially ");
System.out.println(" or fully) the class used to start Java.
");
-System.out.println(" If no options are given, lists Java
processes (same as -p). ");
+System.out.println(" If no options are given, lists Java
processes (same as -l). ");
System.out.println("
");
System.out.println(" PerfCounter.print display the counters
exposed by this process ");
System.out.println(" -f read and execute commands from the
file ");
diff --git a/test/sun/tools/jcmd/usage.out b/test/sun/tools/jcmd/usage.out
--- a/test/sun/tools/jcmd/usage.out
+++ b/test/sun/tools/jcmd/usage.out
@@ -7,7 +7,7 @@
If the pid is 0, commands will be sent to all Java processes.
The main class argument will be used to match (either partially
or fully) the class used to start Java.
- If no options are given, lists Java processes (same as -p).
+ If no options are given, lists Java processes (same as -l).
PerfCounter.print display the counters exposed by this process
-f read and execute commands from the file
Thanks,
Yuji
Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable
Hi all,
I caught an unexpected java.lang.ArithmeticException by CLHSDB through
jhsdb as below.
-
./jhsdb clhsdb --pid 16809
Attaching to process 16809, please wait...
hsdb> class java/lang/ArithmeticException
java/lang/ArithmeticException @0x000100011958
hsdb> class java
class not found: java
hsdb> class java/lang
Error: java.lang.ArithmeticException: / by zero
-
I think that CLHSDB returns "class not found: java/lang". But
ArithmetricException is returned instead.
CLHSDB tries to search the given class name from the regular symbol
table and the shared symbol table.
And called the probe function of the shared symbol table does not
support a case of the empty bucket such as below expression
> long index = hash % bucketCount();
then, throws ArithmetricException.
The stack trace of this java.lang.ArithmeticException is here.
--
java.lang.ArithmeticException: / by zero
at
sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
at
sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
at
sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
at
jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
at
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
at
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
at
jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at
jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
at
jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
at
jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
at
sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
at sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
at
sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
at
sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
--
I have created a patch from jdk9/dev/hotspot (changeset:
9625:de592ea5f7ba) as below, and checked to return "class not found
java/lang" correctly. Please review it.
diff --git
a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
--- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
+++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
@@ -86,6 +86,10 @@
Address baseAddress = baseAddressField.getValue(addr);
Address bucket = bucketsField.getValue(addr);
Address bucketEnd = bucket;
+
+if (bucketCount() == 0) {
+ return null;
+}
long index = hash % bucketCount();
int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
uintSize, true);
int bucketOffset = bucketOffset(bucketInfo);
Thanks,
Yuji
Re: Potential infinite waiting at JMXConnection#createConnection
Hi all,
If Shanliang cannot review, someone could review it?
I reported this issue first at the below.
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html
http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-May/017241.html
Hope this patch helps to community.
Thanks,
Yuji
2015-12-10 22:40 GMT+09:00 KUBOTA Yuji :
> Hi Shanliang and all,
>
> Sorry my reply is too late. But, finally, I reproduced this issue by
> following test program! :)
> Could you please review test program and my patch ?
>
> The test program includes some files, but I do not have an account of
> openjdk, so I push it on icedtea server as below.
>
> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f
>
> The test program starts a simple sleep server program (JMXSSLServer)
> on external jdb process with a breakpoint at
> sun.security.ssl.ServerHandshaker.clientHello set. It then starts a
> client process (JMXSSLCient) which tries to connect the sleep/jdb
> process.
> ServerHandshaker.clientHello responds to the client hello message and
> sends SSL record back. By setting breakpont in that function, we can
> emulate this issue in which client keeps waiting SSL record from
> server.
> Now, JMXConnectorFactory.connect() ignores
> sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL
> record) from server INFINITELY. Once my patch (jdk9.patch) was added,
> then the client will return 0 when the connection timeout happen by
> sun.rmi.transport.tcp.responseTimeout.
> And test program returns the client's return code.
>
> You can reproduce infinite waiting by the below.
> * hg clone
> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/
> * cd fixLoopAtJMXConnectorFactory/testProgram
> * set JAVA_HOME
> * mvn package
> * setting debugcontrol.properties if you need.
> * *NOTE* This test program will stop for "debugcontroltest.stop_time" ms.
> * ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar
> debugcontrol.DebugController
>
> * The result by JDK without my patch.
> The client throws java.net.ConnectException after sending quit to jdb.
> --
> [INFO] Server process args
> args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb
> :
> :
> cli-out: [INFO] Service URL:
> service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi
> ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello
> ser-out:
> ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1",
> sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0
> ser-out:
> [INFO] sending quit to jdb
> ser-err: RMI TCP Connection(2)-127.0.0.1[1]
> cli-err: java.rmi.ConnectException: Connection refused to host:
> 127.0.0.1; nested exception is:
> cli-err:java.net.ConnectException: Connection refused
> cli-err:at
> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> cli-err:at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> cli-err:at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> cli-err:at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130)
> cli-err:at
> javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown
> Source)
> cli-err:at
> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432)
> cli-err:at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308)
> cli-err:at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> cli-err:at
> debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51)
> cli-err:at debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34)
> cli-err: Caused by: java.net.ConnectException: Connection refused
> cli-err:at java.net.PlainSocketImpl.socketConnect(Native Method)
> cli-err:at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> cli-err:at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> cli-err:at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> cli-err:at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> cli-err:at java.net.Socket.connect(Socket.java:589)
> cli-err:at
> sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668)
> cli-err:at
> sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427)
> cli-err:at
> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88)
> cli-err:at
> javax.rmi.ssl.SslRMIClientSocketFactor
HSDB could not terminate when launched on CLI.
Hi all,
When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
not terminate after throwing HeadlessException.
HSDB starts WorkerThread before making the JFrame. If we run HSDB on
CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the
WorkerThread has never shutdown, then HSDB can not terminate.
-
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an
operation which requires it.
at
java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205)
at java.awt.Window.(Window.java:535)
at java.awt.Frame.(Frame.java:422)
at javax.swing.JFrame.(JFrame.java:224)
at sun.jvm.hotspot.HSDB.run(HSDB.java:140)
at sun.jvm.hotspot.HSDB.main(HSDB.java:53)
at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167)
at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339)
## Waiting for the shutdown of WorkerThread forever... ###
-
I have created a patch from jdk9/dev/hotspot (changeset:
9625:de592ea5f7ba) as below. Please review it !
diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
--- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
+++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
@@ -137,15 +137,16 @@
return;
}
+// Make frame at first, then initialize agent.
+frame = new JFrame("HSDB - HotSpot Debugger");
+frame.setSize(800, 600);
+frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
+
agent = new HotSpotAgent();
workerThread = new WorkerThread();
attachMenuItems = new java.util.ArrayList();
detachMenuItems = new java.util.ArrayList();
-frame = new JFrame("HSDB - HotSpot Debugger");
-frame.setSize(800, 600);
-frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
-
JMenuBar menuBar = new JMenuBar();
//
Thanks,
Yuji
Re: Potential infinite waiting at JMXConnection#createConnection
Hi Shanliang and all,
Sorry my reply is too late. But, finally, I reproduced this issue by
following test program! :)
Could you please review test program and my patch ?
The test program includes some files, but I do not have an account of
openjdk, so I push it on icedtea server as below.
http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f
The test program starts a simple sleep server program (JMXSSLServer)
on external jdb process with a breakpoint at
sun.security.ssl.ServerHandshaker.clientHello set. It then starts a
client process (JMXSSLCient) which tries to connect the sleep/jdb
process.
ServerHandshaker.clientHello responds to the client hello message and
sends SSL record back. By setting breakpont in that function, we can
emulate this issue in which client keeps waiting SSL record from
server.
Now, JMXConnectorFactory.connect() ignores
sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL
record) from server INFINITELY. Once my patch (jdk9.patch) was added,
then the client will return 0 when the connection timeout happen by
sun.rmi.transport.tcp.responseTimeout.
And test program returns the client's return code.
You can reproduce infinite waiting by the below.
* hg clone
http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/
* cd fixLoopAtJMXConnectorFactory/testProgram
* set JAVA_HOME
* mvn package
* setting debugcontrol.properties if you need.
* *NOTE* This test program will stop for "debugcontroltest.stop_time" ms.
* ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar
debugcontrol.DebugController
* The result by JDK without my patch.
The client throws java.net.ConnectException after sending quit to jdb.
--
[INFO] Server process args
args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb
:
:
cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi
ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello
ser-out:
ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1",
sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0
ser-out:
[INFO] sending quit to jdb
ser-err: RMI TCP Connection(2)-127.0.0.1[1]
cli-err: java.rmi.ConnectException: Connection refused to host:
127.0.0.1; nested exception is:
cli-err:java.net.ConnectException: Connection refused
cli-err:at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
cli-err:at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
cli-err:at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
cli-err:at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130)
cli-err:at
javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown
Source)
cli-err:at
javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432)
cli-err:at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308)
cli-err:at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
cli-err:at
debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51)
cli-err:at debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34)
cli-err: Caused by: java.net.ConnectException: Connection refused
cli-err:at java.net.PlainSocketImpl.socketConnect(Native Method)
cli-err:at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
cli-err:at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
cli-err:at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
cli-err:at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
cli-err:at java.net.Socket.connect(Socket.java:589)
cli-err:at
sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668)
cli-err:at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427)
cli-err:at
sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88)
cli-err:at
javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:121)
cli-err:at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
cli-err:... 9 more
[INFO] Thu Dec 10 16:16:50 JST 2015 Client done. Result code: 2
[INFO] Client took 114462 msec.
* By JDK 9 with my patch.
The client got java.net.SocketTimeoutException after the connection
timeout happen, then return 0.
--
[INFO] Server process args
args[0]
/workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/jdb
args[1] -classpath
args[2] target/classes
args[3] -J-Duser.language=en
args[4] -Dcom.sun.management.jmxremote.port=9876
args[5] -Dcom.sun.management.jmxremote.password.file=jmxremote.password
args[6] -Djavax.net.ssl.keyStore=jmx-test-cert.pkcs12
args[7] -Djavax.net.ssl.keyStoreType=pkcs12
args[8] -Djavax.net.ssl.keyStorePa
Re: Potential infinite waiting at JMXConnection#createConnection
Hi Shanliang,
Thanks you for your help!
RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE is a nice workaround.
However, many users believe sun.rmi.transport.tcp.responseTimeout to
specify the timeout, e.g. the second flush() of
TCPChannel#createConnection [2]. In really, the first flush()[3] is
not affected by sun.rmi.transport.tcp.responseTimeout, and will be the
(potential) infinite waiting by bad luck. So I think openjdk should
fix it.
[2]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296
[3]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227
Thanks,
Yuji
2015-05-05 2:03 GMT+09:00 Shanliang Jiang :
> Hi Yuji,
>
> (I reply to serviceability alias)
>
> When you create a RMI server connector, you can specify a
> RMIClientSocketFactory by RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE, this allows
> you to specify your SoTimeout.
>
> Hope this helps.
>
> Shanliang
>
>
>
> KUBOTA Yuji wrote:
>
> Hi all,
>
> I want to contribute this issue.
> If there are a problem about this patch or a better way for openjdk
> community, please advise me.
>
> Thanks for
>
> 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji :
>
>
> Hi all,
>
> I found an infinite waiting at TCPChannel#createConnection.
> This method flushes the DataOutputStream without the socket timeout settings
> when choose stream protocol [1].
>
> If connection lost (the destination server do no return response)
> during the flush,
> this method has possibilities to take long time beyond the expectations
> at java.net.SocketInputStream.socketRead0 as following stack trace.
>
> stack trace :
> at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java)
> at sun.security.ssl.InputRecord.read(InputRecord.java)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
> at java.io.DataOutputStream.flush(DataOutputStream.java)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
> at
> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
> at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)
>
> When create connection, we cannot set the timeout by properties.
> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite.
> So I wrote a patch to fix this infinite waiting by using property-configured
> value:
> sun.rmi.transport.tcp.responseTimeout.
>
> Please review this patch. :)
>
> Note: My OCA has been processed a few hour ago, so my name may take a
> short time to
> appear on the OCA signatories page.
>
> Thanks,
> KUBOTA Yuji
>
> [1]:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191
>
> diff --git
> a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> @@ -222,20 +222,34 @@
> // choose protocol (single op if not reusable socket)
> if (!conn.isReusable()) {
> out.writeByte(TransportConstants.SingleOpProtocol);
> } else {
> out.writeByte(TransportConstants.StreamProtocol);
> +
> +int usableSoTimeout = 0;
> +try {
> +/*
> + * If socket factory had set a zero timeout on its
> own,
> + * then set the property-configured value to
> prevent
> + * an infinite waiti
Re: Potential infinite waiting at JMXConnection#createConnection
2015-05-06 19:48 GMT+09:00 Shanliang Jiang : > To reproduce the bug, I was thinking to use > RMI_SERVER_SOCKET_FACTORY_ATTRIBUTE to specify a user socket server, which > will not response any client connection request, I did not yet test this > solution. Thanks, I will try to reproduce with the attribute at first. Yuji > Shanliang > > > Thanks, > Yuji > > 2015-05-06 18:51 GMT+09:00 Shanliang Jiang : >> >> Hi Yuji, >> >> I think better at first to create a bug at: >> https://bugs.openjdk.java.net/secure/Dashboard.jspa >> >> It looks like an issue for me, it must be possible to have a test to >> reproduce the issue. It is helpful to attach the test and present your >> solution in the bug. >> >> I can help if you need any help to create the bug. >> >> Shanliang >> >> >> >> KUBOTA Yuji wrote: >> >> My apologies for re-post, I forgot to register serviceability-dev before the >> last post. >> >> Hi Shanliang, >> >> Thanks you for your help! >> >> RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE is a nice workaround. >> >> However, many users believe sun.rmi.transport.tcp.responseTimeout to specify >> the timeout, >> e.g. the second flush() of TCPChannel#createConnection [2]. >> In really, the first flush() [3] is not affected by >> sun.rmi.transport.tcp.responseTimeout, >> and will be the (potential) infinite waiting by bad luck. So I think openjdk >> should fix it for users. >> >> [2]: >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296 >> [3]: >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227 >> >> Thanks, >> Yuji >> >> 2015-05-05 2:03 GMT+09:00 Shanliang Jiang : >> > Hi Yuji, >> > >> > (I reply to serviceability alias) >> > >> > When you create a RMI server connector, you can specify a >> > RMIClientSocketFactory by RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE, this allows >> > you to specify your SoTimeout. >> > >> > Hope this helps. >> > >> > Shanliang >> > >> > >> > >> > KUBOTA Yuji wrote: >> > >> > Hi all, >> > >> > I want to contribute this issue. >> > If there are a problem about this patch or a better way for openjdk >> > community, please advise me. >> > >> > Thanks for >> > >> > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : >> > >> > >> > Hi all, >> > >> > I found an infinite waiting at TCPChannel#createConnection. >> > This method flushes the DataOutputStream without the socket timeout >> > settings >> > when choose stream protocol [1]. >> > >> > If connection lost (the destination server do no return response) >> > during the flush, >> > this method has possibilities to take long time beyond the expectations >> > at java.net.SocketInputStream.socketRead0 as following stack trace. >> > >> > stack trace : >> > at java.net.SocketInputStream.socketRead0(SocketInputStream.java) >> > at java.net.SocketInputStream.read(SocketInputStream.java) >> > at java.net.SocketInputStream.read(SocketInputStream.java) >> > at sun.security.ssl.InputRecord.readFully(InputRecord.java) >> > at sun.security.ssl.InputRecord.read(InputRecord.java) >> > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) >> > at >> > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) >> > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) >> > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) >> > at >> > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) >> > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) >> > at java.io.DataOutputStream.flush(DataOutputStream.java) >> > at >> > sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) >> > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) >> > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) >> > at javax.management.remote.rmi.RMIServerImpl_Stub.newClient >> > at >> > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
Re: Potential infinite waiting at JMXConnection#createConnection
Hi Shanliang, Many thanks for your help! I do not have any role yet. So I can not create a new bug at JBS. It's a reason why I submitted a mail with my patch at first. This issue is caused by a rare network problem during the flush() [3] . I got this infinite loop only once. So I will try to write test or/and client codes with BCI for reproduction. Thanks, Yuji 2015-05-06 18:51 GMT+09:00 Shanliang Jiang : > Hi Yuji, > > I think better at first to create a bug at: > https://bugs.openjdk.java.net/secure/Dashboard.jspa > > It looks like an issue for me, it must be possible to have a test to > reproduce the issue. It is helpful to attach the test and present your > solution in the bug. > > I can help if you need any help to create the bug. > > Shanliang > > > > KUBOTA Yuji wrote: > > My apologies for re-post, I forgot to register serviceability-dev before > the last post. > > Hi Shanliang, > > Thanks you for your help! > > RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE is a nice workaround. > > However, many users believe sun.rmi.transport.tcp.responseTimeout > to specify the timeout, > e.g. the second flush() of TCPChannel#createConnection [2]. > In really, the first flush() [3] is not affected by > sun.rmi.transport.tcp.responseTimeout, > and will be the (potential) infinite waiting by bad luck. So I think > openjdk should fix it for users. > > [2]: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296 > [3]: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227 > > Thanks, > Yuji > > 2015-05-05 2:03 GMT+09:00 Shanliang Jiang : > > Hi Yuji, > > > > (I reply to serviceability alias) > > > > When you create a RMI server connector, you can specify a > > RMIClientSocketFactory by RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE, this > allows > > you to specify your SoTimeout. > > > > Hope this helps. > > > > Shanliang > > > > > > > > KUBOTA Yuji wrote: > > > > Hi all, > > > > I want to contribute this issue. > > If there are a problem about this patch or a better way for openjdk > > community, please advise me. > > > > Thanks for > > > > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : > > > > > > Hi all, > > > > I found an infinite waiting at TCPChannel#createConnection. > > This method flushes the DataOutputStream without the socket timeout > settings > > when choose stream protocol [1]. > > > > If connection lost (the destination server do no return response) > > during the flush, > > this method has possibilities to take long time beyond the expectations > > at java.net.SocketInputStream.socketRead0 as following stack trace. > > > > stack trace : > > at java.net.SocketInputStream.socketRead0(SocketInputStream.java) > > at java.net.SocketInputStream.read(SocketInputStream.java) > > at java.net.SocketInputStream.read(SocketInputStream.java) > > at sun.security.ssl.InputRecord.readFully(InputRecord.java) > > at sun.security.ssl.InputRecord.read(InputRecord.java) > > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) > > at > > > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) > > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) > > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) > > at > > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) > > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) > > at java.io.DataOutputStream.flush(DataOutputStream.java) > > at > > sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) > > at > sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) > > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) > > at javax.management.remote.rmi.RMIServerImpl_Stub.newClient > > at > > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) > > at > > javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) > > at > > > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) > > > > When create connection, we cannot set the timeout by properties. > > Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. > > So I wrote a patch to fix this infinite waiting by using >
Re: Potential infinite waiting at JMXConnection#createConnection
My apologies for re-post, I forgot to register serviceability-dev before
the last post.
Hi Shanliang,
Thanks you for your help!
RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE is a nice workaround.
However, many users believe sun.rmi.transport.tcp.responseTimeout
to specify the timeout,
e.g. the second flush() of TCPChannel#createConnection [2].
In really, the first flush() [3] is not affected by
sun.rmi.transport.tcp.responseTimeout,
and will be the (potential) infinite waiting by bad luck. So I think
openjdk should fix it for users.
[2]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296
[3]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227
Thanks,
Yuji
2015-05-05 2:03 GMT+09:00 Shanliang Jiang :
> Hi Yuji,
>
> (I reply to serviceability alias)
>
> When you create a RMI server connector, you can specify a
> RMIClientSocketFactory by RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE, this allows
> you to specify your SoTimeout.
>
> Hope this helps.
>
> Shanliang
>
>
>
> KUBOTA Yuji wrote:
>
> Hi all,
>
> I want to contribute this issue.
> If there are a problem about this patch or a better way for openjdk
> community, please advise me.
>
> Thanks for
>
> 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji :
>
>
> Hi all,
>
> I found an infinite waiting at TCPChannel#createConnection.
> This method flushes the DataOutputStream without the socket timeout
settings
> when choose stream protocol [1].
>
> If connection lost (the destination server do no return response)
> during the flush,
> this method has possibilities to take long time beyond the expectations
> at java.net.SocketInputStream.socketRead0 as following stack trace.
>
> stack trace :
> at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java)
> at sun.security.ssl.InputRecord.read(InputRecord.java)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
> at java.io.DataOutputStream.flush(DataOutputStream.java)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
> at
> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
> at
>
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)
>
> When create connection, we cannot set the timeout by properties.
> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite.
> So I wrote a patch to fix this infinite waiting by using
property-configured
> value:
> sun.rmi.transport.tcp.responseTimeout.
>
> Please review this patch. :)
>
> Note: My OCA has been processed a few hour ago, so my name may take a
> short time to
> appear on the OCA signatories page.
>
> Thanks,
> KUBOTA Yuji
>
> [1]:
>
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191
>
> diff --git
> a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> @@ -222,20 +222,34 @@
> // choose protocol (single op if not reusable socket)
> if (!conn.isReusable()) {
> out.writeByte(TransportConstants.SingleOpProtocol);
> } else {
> out.writeByte(TransportConstants.StreamProtocol);
> +
> +int usableSoTimeout = 0;
> +try {
> +/*
> + * If socket factory had set a zero timeout on
its
> own,
> +
