Integrated: JDK-8260426: awt debug_mem.c DMem_AllocateBlock might leak memory
On Wed, 27 Jan 2021 09:56:05 GMT, Matthias Baesken wrote: > It seems that the function DMem_AllocateBlock (debug_mem.c) has an early > return that might lead to memory leaks. > See also the sonar issue Potential leak of memory pointed to by 'header' : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B7zBBG2CXpcngZM&resolved=false&severities=BLOCKER&types=BUG This pull request has now been integrated. Changeset: 11a70d11 Author:Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/11a70d11 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8260426: awt debug_mem.c DMem_AllocateBlock might leak memory Reviewed-by: psadhukhan, aivanov - PR: https://git.openjdk.java.net/jdk/pull/2252
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Thu, 28 Jan 2021 00:41:13 GMT, Sergey Bylokhov wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611: >> >>> 2609: Sleep(100); >>> 2610: } >>> 2611: >> >> It can cause infinite looping as the message queue to get DISPOSE events is >> removed so if we are not getting disposed by now, we probably will not get >> DISPOSE event ever causing infinite loop. >> XToolkit, LWToolkit does not have this infinite loop. > > My point is that this is not a test bug, so the test should not be changed. Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"? - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
> This test was failing in our nightly mach5 testing. Appropriate stability > code in form of waitForIdle and delay is added. > mach5 job running for several iterations on all platforms is ok. Link in JBS. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test changes reverted - Changes: - all: https://git.openjdk.java.net/jdk/pull/2220/files - new: https://git.openjdk.java.net/jdk/pull/2220/files/87d371ad..6fdcc0d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2220&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2220&range=01-02 Stats: 32 lines in 1 file changed: 0 ins; 12 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2220.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2220/head:pull/2220 PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v2]
On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Prevent infinite loop > > src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611: > >> 2609: Sleep(100); >> 2610: } >> 2611: > > It can cause infinite looping as the message queue to get DISPOSE events is > removed so if we are not getting disposed by now, we probably will not get > DISPOSE event ever causing infinite loop. > XToolkit, LWToolkit does not have this infinite loop. My point is that this is not a test bug, so the test should not be changed. - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v2]
On Wed, 27 Jan 2021 12:39:01 GMT, Prasanta Sadhukhan
wrote:
>> This test was failing in our nightly mach5 testing. Appropriate stability
>> code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Prevent infinite loop
test/jdk/javax/swing/JColorChooser/Test6827032.java line 78:
> 76: } finally {
> 77: if (frame != null) {
> 78: SwingUtilities.invokeAndWait(() -> frame.dispose());
Shall the frame be `volatile` too? It's accessed from main thread for the
null-check.
-
PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: JDK-8260426: awt debug_mem.c DMem_AllocateBlock might leak memory
On Wed, 27 Jan 2021 09:56:05 GMT, Matthias Baesken wrote: > It seems that the function DMem_AllocateBlock (debug_mem.c) has an early > return that might lead to memory leaks. > See also the sonar issue Potential leak of memory pointed to by 'header' : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B7zBBG2CXpcngZM&resolved=false&severities=BLOCKER&types=BUG Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2252
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v2]
On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan wrote: >> This test was failing in our nightly mach5 testing. Appropriate stability >> code in form of waitForIdle and delay is added. >> mach5 job running for several iterations on all platforms is ok. Link in JBS. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit since the last revision: > > Prevent infinite loop src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611: > 2609: Sleep(100); > 2610: } > 2611: It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop. XToolkit, LWToolkit does not have this infinite loop. - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v2]
> This test was failing in our nightly mach5 testing. Appropriate stability > code in form of waitForIdle and delay is added. > mach5 job running for several iterations on all platforms is ok. Link in JBS. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Prevent infinite loop - Changes: - all: https://git.openjdk.java.net/jdk/pull/2220/files - new: https://git.openjdk.java.net/jdk/pull/2220/files/3db928b1..87d371ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2220&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2220&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2220.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2220/head:pull/2220 PR: https://git.openjdk.java.net/jdk/pull/2220
Integrated: 8260314: Replace border="1" on tables with CSS
On Sat, 23 Jan 2021 19:06:05 GMT, Alexey Ivanov wrote:
> Replace presentational attribute `border="1"` on `` element with CSS
> styles:
> table {border: outset 1px}
> th, td {border: inset 1px}
>
> These declarations produce the same rendering as the default one in Firefox
> and Edge.
>
> Another option is to use `solid` in both cases.
This pull request has now been integrated.
Changeset: 7ed591cc
Author:Alexey Ivanov
URL: https://git.openjdk.java.net/jdk/commit/7ed591cc
Stats: 36 lines in 6 files changed: 0 ins; 1 del; 35 mod
8260314: Replace border="1" on tables with CSS
Reviewed-by: serb
-
PR: https://git.openjdk.java.net/jdk/pull/2210
Re: RFR: JDK-8260426: awt debug_mem.c DMem_AllocateBlock might leak memory
On Wed, 27 Jan 2021 09:56:05 GMT, Matthias Baesken wrote: > It seems that the function DMem_AllocateBlock (debug_mem.c) has an early > return that might lead to memory leaks. > See also the sonar issue Potential leak of memory pointed to by 'header' : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B7zBBG2CXpcngZM&resolved=false&severities=BLOCKER&types=BUG Marked as reviewed by psadhukhan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2252
RFR: JDK-8260426: awt debug_mem.c DMem_AllocateBlock might leak memory
It seems that the function DMem_AllocateBlock (debug_mem.c) has an early return that might lead to memory leaks. See also the sonar issue Potential leak of memory pointed to by 'header' : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B7zBBG2CXpcngZM&resolved=false&severities=BLOCKER&types=BUG - Commit messages: - JDK-8260426 Changes: https://git.openjdk.java.net/jdk/pull/2252/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2252&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260426 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2252/head:pull/2252 PR: https://git.openjdk.java.net/jdk/pull/2252
