On Mon, 15 Jul 2024 18:08:26 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Mon, 15 Jul 2024 18:08:26 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.resume(), which decrements the thread2 suspendCount to 1,
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Fri, 12 Jul 2024 22:36:56 GMT, Daniel D. Daugherty
wrote:
> Is there any chance that all the `Breakpint` typos can be fixed?
There was only one and I fixed it already.
-
PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2226537454
On Fri, 12 Jul 2024 17:02:56 GMT, Chris Plummer wrote:
>> The original code had 2 vm.resume() - one on them to match vm.suspend() and
>> 2nd one to allow debugee to continue on error.
>> Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2
>> conditional (on error).
>> Theo
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Fri, 12 Jul 2024 08:02:31 GMT, Alex Menkov wrote:
>> First just to clarify a general JDI feature about thread suspending and
>> resuming. You can undo a ThreadReference.suspend() or a thread suspended as
>> the result of an event by dong a vm.resume(). This is documented in the JDI
>> API s
On Fri, 12 Jul 2024 04:08:25 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
>> line 382:
>>
>>> 380: if (expresult != returnCode0) {
>>> 381: vm.resume();
>>> 382: vm.resume(); // for case err
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Fri, 12 Jul 2024 02:44:28 GMT, David Holmes wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright and jcheck error
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
> line
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.resume(), which decrements the thread2 suspendCount to 1,
On Thu, 11 Jul 2024 15:58:13 GMT, Chris Plummer wrote:
>> Yes. thread2 is suspended via breakpoint (multiple times). mainThread is
>> suspended by the one place in the test that does a vm.suspend(), which is
>> near the end of the test. This is the problematic suspend because sometimes
>> it i
On Thu, 11 Jul 2024 16:01:27 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On Thu, 11 Jul 2024 14:09:57 GMT, Chris Plummer wrote:
>> Sorry I'm unclear on the different threads involved here. IIUC the
>> vm.suspend comes from the debugger, and the mainthread and thread-2 are both
>> threads in the debuggee, being suspended at different times?
>
> Yes. thread2 is suspen
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.resume(), which decrements the thread2 suspendCount to 1,
On Thu, 11 Jul 2024 07:13:17 GMT, David Holmes wrote:
>> Which logging should be removed? Alex suggest the logging between
>> breakpoints 2 and 3, but even that is not enough. There is logging after
>> breakpoint 3, and that happens before the vm.resume() is done. I'm not
>> saying this can't
On Thu, 11 Jul 2024 04:43:49 GMT, Chris Plummer wrote:
>>> mainThead is suspended and is holding a println related lock, and thread2
>>> is stuck on the 2nd log call in runt2 awaiting the same lock.
>>
>> The classic example of why suspension is fraught with peril - the target
>> must be guara
On Thu, 11 Jul 2024 01:57:33 GMT, David Holmes wrote:
>> I believe we've done quite a few short sleeps like this in the past. Scaling
>> is not really an issue. It should only require at most a few ms, even with
>> -Xcomp, so we wait 1000ms and then never have to think about the timing
>> agai
On Wed, 10 Jul 2024 23:09:05 GMT, Chris Plummer wrote:
>> Adding a `sleep()` between two statements does not scale when the test in
>> question is under different loads or run with different options. All it will
>> do
>> is make a hang more rare (and frustrating to analyze).
>>
>> We do use sho
On Wed, 10 Jul 2024 22:29:08 GMT, Daniel D. Daugherty
wrote:
>> Removing log() statements to fix the problem can be risky because someone
>> could re-add them in the future. What about my idea of doing a short sleep
>> before the vm.suspend() to make sure the main thread has advanced to the
>
On Wed, 10 Jul 2024 21:28:50 GMT, Chris Plummer wrote:
>> Thank you for the confirming the reason of the timeout.
>>
>> To be more clear about my point:
>> The test has 3 scenarios (see the test description):
>> ThreadReference.resume() resumes the thread suspended with:
>> * - with thread2.s
On Wed, 10 Jul 2024 20:56:17 GMT, Alex Menkov wrote:
>> I was able to add synchronization between the debugger and debuggee to fix
>> this issue, but I don't really like the solution. It just adds more
>> complexity and makes the test even harder to follow. What I'd like to do is
>> just put a
On Wed, 10 Jul 2024 20:50:50 GMT, Chris Plummer wrote:
>> I was finally able to reproduce the issue with the stack dumping support in
>> place. mainThread is in the middle of printing the 1st of the two logs
>> mention above. mainThead is suspended and is holding a println related lock,
>> and
On Wed, 10 Jul 2024 17:10:46 GMT, Chris Plummer wrote:
>>> This does not look correct to me.
>>> This is the last test scenario - thread2.resume should resumes the thread
>>> while vm is suspended.
>>> thread2 should not be blocked on main thread.
>>> Looking at the debuggee I suppose the blocki
On Wed, 10 Jul 2024 06:46:56 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
>> line 356:
>>
>>> 354: }
>>> 355:
>>> 356: // We need to resume the main thread because thread2
>>> might be blocked on it,
>
On Tue, 9 Jul 2024 19:17:26 GMT, Alex Menkov wrote:
> This does not look correct to me.
> This is the last test scenario - thread2.resume should resumes the thread
> while vm is suspended.
> thread2 should not be blocked on main thread.
> Looking at the debuggee I suppose the blocking is possibl
On Tue, 9 Jul 2024 04:43:59 GMT, Chris Plummer wrote:
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.re
On Tue, 9 Jul 2024 04:43:59 GMT, Chris Plummer wrote:
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.re
The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only
thread2 is suspended. It then does a vm.suspend(), which suspends all threads
and bumps the suspendCount of thread2 up to 2. It then does an
eventSet.resume(), which decrements the thread2 suspendCount to 1, so now a
33 matches
Mail list logo
