Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
On Fri, 5 Mar 2021 17:21:36 GMT, Dmitry Markov wrote: >> The IME functions and the DND operation must be executed on the toolkit >> thread. If the DND operation is in progress, the IME API is invoked via >> SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The >> flag isInDoDragDropLoop indicates whether the DND takes place or not. The >> flag works properly if the DND is performed between two Java windows. >> However if anything is dragged from native app, (e.g. Windows FileExplorer) >> to Java the flag is NOT set. That’s the root cause of the hang. >> >> Fix: >> Introduce a new flag to indicate DND operation between Java and native app. >> >> Testing: >> mach5 green > > Dmitry Markov has updated the pull request incrementally with one additional > commit since the last revision: > > Remove flag setting from DragOver Marked as reviewed by kizune (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov wrote: > The IME functions and the DND operation must be executed on the toolkit > thread. If the DND operation is in progress, the IME API is invoked via > SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The > flag isInDoDragDropLoop indicates whether the DND takes place or not. The > flag works properly if the DND is performed between two Java windows. However > if anything is dragged from native app, (e.g. Windows FileExplorer) to Java > the flag is NOT set. That’s the root cause of the hang. > > Fix: > Introduce a new flag to indicate DND operation between Java and native app. > > Testing: > mach5 green @dmarkov20 Sorry I'm not reviewer. It seems Copyright year is not changed. Is it OK ? - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows
On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy wrote: > Printing text using GlyphVector outline has bad quality on printers with low > DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path > coordinates. > Rounding GlyphVector outline coordinates leads to distorted printed text. > > The issue had been reported as JDK-8256264 but was reverted because of the > regression JDK-8259007 "This test printed a blank page". > > The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo() > methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down. > > The regression was in the WPathGraphics.deviceDrawLine() method which uses > wPrinterJob.moveTo()/lineTo() methods without surrounding them with > wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up. > > I tried to put wPrinterJob.beginPath()/endPath() methods around > wPrinterJob.moveTo()/lineTo() in the method WPathGraphics.deviceDrawLine() > but the line was not drawn at all even without scaling coordinates up and > transform down (without JDK-8256264 fix). It looks like GDI treats this case > as an empty shape. > > The proposed fix applies path coordinates and transform scaling only in > WPathGraphics.convertToWPath() method. > The one more PathPrecisionScaleFactorShapeTest.java manual test is added > which checks that all methods that draw paths in WPathGraphics are used: line > in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in > WPathGraphics.convertToWPath() . > > The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were > run on Windows 10 Pro with the fix. > > There are two failed automated tests which fail without the fix as well: > java/awt/print/PrinterJob/GlyphPositions.java > java/awt/print/PrinterJob/PSQuestionMark.java > > The following manual tests have issues on my system: > - `java/awt/print/Dialog/PrintDlgPageable.java` > java.lang.IllegalAccessException: class > com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member > of class PrintDlgPageable with modifiers "public static" > > - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages > radio button, press the print button but the test does not finish and I do > not see any other dialogs with pass/fail buttons. > > - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests > that there is no ClassCastException thrown in printing checkbox and scrollbar > with XAWT. Error. Can't find HTML file: > test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html > > > - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with > instructions is shown but it does not contain print/pass/fail buttons and it > is not possible to close the window. > > - The tests below fail with "Error. Parse Exception: Arguments to `manual' > option not supported: yesno" message: > java/awt/print/Dialog/DialogOrient.java > java/awt/print/Dialog/DialogType.java > java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java > java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java > java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java > java/awt/print/PrinterJob/PageDialogTest.java > java/awt/print/PrinterJob/PageRanges.java > java/awt/print/PrinterJob/PageRangesDlgTest.java > java/awt/print/PrinterJob/PrintGlyphVectorTest.java > java/awt/print/PrinterJob/PrintLatinCJKTest.java > java/awt/print/PrinterJob/PrintTextTest.java > java/awt/print/PrinterJob/SwingUIText.java > java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java > java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java > java/awt/PrintJob/SaveDialogTitleTest.java I'll run the tests for this fix. - PR: https://git.openjdk.java.net/jdk/pull/2756
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
On Fri, 5 Mar 2021 17:21:36 GMT, Dmitry Markov wrote: >> The IME functions and the DND operation must be executed on the toolkit >> thread. If the DND operation is in progress, the IME API is invoked via >> SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The >> flag isInDoDragDropLoop indicates whether the DND takes place or not. The >> flag works properly if the DND is performed between two Java windows. >> However if anything is dragged from native app, (e.g. Windows FileExplorer) >> to Java the flag is NOT set. That’s the root cause of the hang. >> >> Fix: >> Introduce a new flag to indicate DND operation between Java and native app. >> >> Testing: >> mach5 green > > Dmitry Markov has updated the pull request incrementally with one additional > commit since the last revision: > > Remove flag setting from DragOver Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()
On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov wrote: > **Root cause:** > `getPrinterNames()` has two calls to > [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). > The first call is to get the required buffer size to contain the structures > and any strings. The second call is to get the list of printers. > > Yet the list of printers or the names of printers can change between the two > calls. If it happens, the second call to `EnumPrinters` fails but it is not > checked. > > I couldn't reproduce the crash myself. However, I reproduced the failure in > the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming > the printers so that the data doesn't fit into the allocated buffer: > > 1: bResult: 0, cbNeeded: 504, cReturned: 0 > 2: bResult: 0, cbNeeded: 512, cReturned: 0 > !!! error > > During my testing, `cReturned` has always been zero whenever `EnumPrinters` > fails. > > The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` > buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line > utf_str = JNU_NewStringPlatform(env, info4->pPrinterName); > raises Access Violation exception. > > **The fix:** > Check the return value of `EnumPrinters` and allow for 5 retries. If the > function still returns failure, make sure `cReturned` is set to zero. > > I'm going to close > [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and > [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported > previously about the same crash as duplicate of the current > [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829). > > **Testing:** > I used > [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) > for testing, it shows the list of currently available printers. In the > background I ran `PrinterRename.ps1` PowerShell script which remains a > printer, the script is attached to the JBS issue. > > Without the fix, the list of available printers was empty occasionally > because `EnumPrinters` returned failure and set `cReturned` to zero. With the > fix, the list of printers is always filled. Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2836
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
On Fri, 5 Mar 2021 17:21:36 GMT, Dmitry Markov wrote: >> The IME functions and the DND operation must be executed on the toolkit >> thread. If the DND operation is in progress, the IME API is invoked via >> SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The >> flag isInDoDragDropLoop indicates whether the DND takes place or not. The >> flag works properly if the DND is performed between two Java windows. >> However if anything is dragged from native app, (e.g. Windows FileExplorer) >> to Java the flag is NOT set. That’s the root cause of the hang. >> >> Fix: >> Introduce a new flag to indicate DND operation between Java and native app. >> >> Testing: >> mach5 green > > Dmitry Markov has updated the pull request incrementally with one additional > commit since the last revision: > > Remove flag setting from DragOver Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Fri, 5 Mar 2021 11:11:44 GMT, Alan Hayward wrote: >>> I was building this PR on a new machine, and I now get the following error: >>> >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: >>> > error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') >>> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIClientRef client = (MIDIClientRef) NULL; >>> > ^~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: >>> > error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') >>> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIPortRef inPort = (MIDIPortRef) NULL; >>> > ^~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: >>> > error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') >>> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIPortRef outPort = (MIDIPortRef) NULL; >>> > ^~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: >>> > error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned >>> > int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL; >>> > ^~ >>> > 4 errors generated. >>> >>> As far as I can tell the only difference between the two systems is the >>> xcode version: >>> >>> New system (failing) >>> % xcodebuild -version >>> Xcode 12.5 >>> Build version 12E5244e >>> >>> Old system (working) >>> % xcodebuild -version >>> Xcode 12.4 >>> Build version 12D4e >>> >>> Looks like the newer version of Xcode is being a little stricter with >>> casting? >>> Replacing the NULL with 0 seems to fix the issue. >> >> Hello >> there is one issue with the info you provided, it's from Xcode12.5 beta. >> And beta license agreement forbids sharing output of beta version of >> compiler >> So we can't say we have issue with newer xcode beta until that beta went >> public & released. >> Fixing issues you found now will mean someone have violated xcode beta >> license agreement and made these issues public. > >> Hello >> there is one issue with the info you provided, it's from Xcode12.5 beta. >> And beta license agreement forbids sharing output of beta version of >> compiler >> So we can't say we have issue with newer xcode beta until that beta went >> public & released. >> Fixing issues you found now will mean someone have violated xcode beta >> license agreement and made these issues public. > > Ok, I wasn't aware of that. I'll downgrade back to the non-beta version. Hi, @VladimirKempik reported failure of CompressedClassPointers.largeHeapAbove32GTest() with [JDK-8262895](https://bugs.openjdk.java.net/browse/JDK-8262895) on macos_aarch64. He also helped analyzing the issue (thanks!). Apparently the vm has difficulties mapping the heap of 31GB at one of the preferred addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477). This causes the test failure indirectly. IMO it could be worth the effort to find out why the heap cannot be mapped at the preferred addresses. Reviewers should decide on it. I wouldn't be able to do it myself though as I don't have access to a macos_aarch64 system. Alternatively I'd suggest to exlude macos_aarch64 from the subtest largeHeapAbove32GTest. Best regards, Richard. -- Details of the analysis In the following trace we see the vm trying to allocate the heap at addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477) without success: images/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010 heap of size 0x7c100 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0018 heap of size 0x7c100 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0020 heap of size 0x7c100 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0040 heap of size 0x7c100 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0050 heap of size 0x7c100 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008 heap of size 0x7c100
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
> The IME functions and the DND operation must be executed on the toolkit > thread. If the DND operation is in progress, the IME API is invoked via > SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The > flag isInDoDragDropLoop indicates whether the DND takes place or not. The > flag works properly if the DND is performed between two Java windows. However > if anything is dragged from native app, (e.g. Windows FileExplorer) to Java > the flag is NOT set. That’s the root cause of the hang. > > Fix: > Introduce a new flag to indicate DND operation between Java and native app. > > Testing: > mach5 green Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: Remove flag setting from DragOver - Changes: - all: https://git.openjdk.java.net/jdk/pull/2825/files - new: https://git.openjdk.java.net/jdk/pull/2825/files/d9af9879..dbc9dac7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2825=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2825=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2825.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2825/head:pull/2825 PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
On Fri, 5 Mar 2021 17:01:41 GMT, Alexey Ivanov wrote:
>> Dmitry Markov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reuse isInDoDragDropLoop
>
> src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 228:
>
>> 226: HRESULT __stdcall AwtDropTarget::DragOver(DWORD grfKeyState, POINTL pt,
>> DWORD __RPC_FAR *pdwEffect) {
>> 227: TRY;
>> 228: AwtToolkit::GetInstance().isInDoDragDropLoop = TRUE;
>
> This is a new addition. Did you miss this function in previous iteration?
Good catch! Actually that line is harmless but it is really unnecessary. I will
update PR
-
PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
On Fri, 5 Mar 2021 16:06:04 GMT, Dmitry Markov wrote:
>> The IME functions and the DND operation must be executed on the toolkit
>> thread. If the DND operation is in progress, the IME API is invoked via
>> SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The
>> flag isInDoDragDropLoop indicates whether the DND takes place or not. The
>> flag works properly if the DND is performed between two Java windows.
>> However if anything is dragged from native app, (e.g. Windows FileExplorer)
>> to Java the flag is NOT set. That’s the root cause of the hang.
>>
>> Fix:
>> Introduce a new flag to indicate DND operation between Java and native app.
>>
>> Testing:
>> mach5 green
>
> Dmitry Markov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> reuse isInDoDragDropLoop
Marked as reviewed by aivanov (Reviewer).
src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 228:
> 226: HRESULT __stdcall AwtDropTarget::DragOver(DWORD grfKeyState, POINTL pt,
> DWORD __RPC_FAR *pdwEffect) {
> 227: TRY;
> 228: AwtToolkit::GetInstance().isInDoDragDropLoop = TRUE;
This is a new addition. Did you miss this function in previous iteration?
-
PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
On Fri, 5 Mar 2021 12:51:15 GMT, Dmitry Markov wrote: >> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the >> Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while >> dragging something from the native app. > >> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the >> Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while >> dragging something from the native app. > > Initially I didn’t want to touch that flag but after a closer look to > “isInDoDragDropLoop” I think it is OK to reuse the flag. I will update PR > shortly. > @dmarkov20 > I'd like to confirm this issue was not fixed by > [JDK-8261231](https://bugs.openjdk.java.net/browse/JDK-8261231) #2448 ? That's right. This one and JDK-8261231 are two different issues. It is expected that the changes for JDK-8261231 do not fix this. - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
On Fri, 5 Mar 2021 12:53:00 GMT, Dmitry Markov wrote: >>> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the >>> Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true >>> while dragging something from the native app. >> >> Initially I didn’t want to touch that flag but after a closer look to >> “isInDoDragDropLoop” I think it is OK to reuse the flag. I will update PR >> shortly. > >> @dmarkov20 >> I'd like to confirm this issue was not fixed by >> [JDK-8261231](https://bugs.openjdk.java.net/browse/JDK-8261231) #2448 ? > > That's right. This one and JDK-8261231 are two different issues. It is > expected that the changes for JDK-8261231 do not fix this. I have update the fix: reuse isInDoDragDropLoop flag instead of introducing a new one. @mrserb @aivanov-jdk Could you take a look, please? - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
> The IME functions and the DND operation must be executed on the toolkit > thread. If the DND operation is in progress, the IME API is invoked via > SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The > flag isInDoDragDropLoop indicates whether the DND takes place or not. The > flag works properly if the DND is performed between two Java windows. However > if anything is dragged from native app, (e.g. Windows FileExplorer) to Java > the flag is NOT set. That’s the root cause of the hang. > > Fix: > Introduce a new flag to indicate DND operation between Java and native app. > > Testing: > mach5 green Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: reuse isInDoDragDropLoop - Changes: - all: https://git.openjdk.java.net/jdk/pull/2825/files - new: https://git.openjdk.java.net/jdk/pull/2825/files/6d7502a4..d9af9879 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2825=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2825=00-01 Stats: 11 lines in 3 files changed: 1 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2825.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2825/head:pull/2825 PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
On Fri, 5 Mar 2021 01:34:04 GMT, Sergey Bylokhov wrote: > Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the > Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while > dragging something from the native app. Initially I didn’t want to touch that flag but after a closer look to “isInDoDragDropLoop” I think it is OK to reuse the flag. I will update PR shortly. - PR: https://git.openjdk.java.net/jdk/pull/2825
Re: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()
On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov wrote: > **Root cause:** > `getPrinterNames()` has two calls to > [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). > The first call is to get the required buffer size to contain the structures > and any strings. The second call is to get the list of printers. > > Yet the list of printers or the names of printers can change between the two > calls. If it happens, the second call to `EnumPrinters` fails but it is not > checked. > > I couldn't reproduce the crash myself. However, I reproduced the failure in > the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming > the printers so that the data doesn't fit into the allocated buffer: > > 1: bResult: 0, cbNeeded: 504, cReturned: 0 > 2: bResult: 0, cbNeeded: 512, cReturned: 0 > !!! error > > During my testing, `cReturned` has always been zero whenever `EnumPrinters` > fails. > > The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` > buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line > utf_str = JNU_NewStringPlatform(env, info4->pPrinterName); > raises Access Violation exception. > > **The fix:** > Check the return value of `EnumPrinters` and allow for 5 retries. If the > function still returns failure, make sure `cReturned` is set to zero. > > I'm going to close > [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and > [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported > previously about the same crash as duplicate of the current > [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829). > > **Testing:** > I used > [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) > for testing, it shows the list of currently available printers. In the > background I ran `PrinterRename.ps1` PowerShell script which remains a > printer, the script is attached to the JBS issue. > > Without the fix, the list of available printers was empty occasionally > because `EnumPrinters` returned failure and set `cReturned` to zero. With the > fix, the list of printers is always filled. Marked as reviewed by psadhukhan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2836
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Thu, 4 Mar 2021 18:19:33 GMT, Vladimir Kempik wrote: > Hello > there is one issue with the info you provided, it's from Xcode12.5 beta. > And beta license agreement forbids sharing output of beta version of > compiler > So we can't say we have issue with newer xcode beta until that beta went > public & released. > Fixing issues you found now will mean someone have violated xcode beta > license agreement and made these issues public. Ok, I wasn't aware of that. I'll downgrade back to the non-beta version. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()
On Thu, 4 Mar 2021 22:09:55 GMT, Phil Race wrote: > I guess this is OK and yes we should have been checking this. > Not sure we really got to the bottom of the real world problem because I'd > expect the 2nd call just milliseconds after the first. But it could be that > this happens during some system updates and we get one printer reconfigured > message followed by another .. Most of the time, the crash happens when a client reconnects to their active session where a JVM is already running. On reconnect, the list of printers is synced with the local printers on the client. In such a scenario, other software could also update its list of printers as well as repaint its UI. If the system is under high load, it's not impossible to have a long enough pause between the calls. - PR: https://git.openjdk.java.net/jdk/pull/2836
Re: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()
On Fri, 5 Mar 2021 03:49:22 GMT, Prasanta Sadhukhan wrote: >> I guess since we are changing this method anyway, can we use >> PRINTER_ENUM_CONNECTIONS flag instead of hardcoded 4 so that it is more >> informative!! > > ok, it is for flags and not for level. please ignore > > > Don't we need to check that this method call succeeds? Probably it is a crash > reason when the EnumPrinters fails but we use cbNeeded anyway for array > allocation? `EnumPrinters` always returns failure here because zero-sized buffer is too small to contain any data. - PR: https://git.openjdk.java.net/jdk/pull/2836
