Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
I’m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. — Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primož Kokol wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primož Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this procedure (from >>> pull/417 request): >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> We wanted to use it in our existing application (Java 11.0.10) to debug >> an >>> issue where the application would hang/freeze for no obvious reason >> because >>> of WebKit. >>> >>> In order to use this build we've manually overridden javafx-*.jar files >> in >>> our application with the ones from the above build. >>> We've also placed all produced DLL files in our application's "bin" >> folder >>> so they are properly picked up (I've verified and I can confirm that >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> After using this native debug build, the application will crash instead >>> with: >>> Unhandled exception at 0x7FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> It looks like it happens when JS code calls Java method. >>> >>> There is the call stack at the time when exception happens: >>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ >>> Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::jsDynamicCast>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line >>> 182 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> const >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >>> Line 212 C++ Symbols loaded. >>> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> loaded. >>> >>> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >>> Line 124 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >> loaded. >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >>> Symbols loaded. >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> const >>> JSC::Instruction * pc) Line 833 C++
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Fri, 12 Mar 2021 14:18:59 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java >> line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights >>> reserved. >> >> Minor year correction-> `Copyright (c) 2021,` >> Similar change in other test files. > > Done, so it's the year where changes happened, ok! In general, the pattern is: `year_created, year_last_modified,` (with the last modified year omitted if it's the same as the creation year). - PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Fri, 12 Mar 2021 21:12:41 GMT, Martin Fox wrote: >> I see that the Windows pre-submit test build failed. It's clearly not >> related to anything in this PR, so it can be ignored. >> >> I'll review this PR later (hopefully next week some time), but I have a >> couple general comments: >> >> 1. Would it be possible to provide an automated test? Maybe not since it is >> sensitive to the keyboard layout. >> 2. For the related bugs, we can either close them as duplicates of this bug >> or use the `/solves` command to list them here. Generally, we would do the >> former in the case it really is a single fix, as this seems to be. That's >> what I'll do once this bug is integrated unless there is a good reason not >> to. Normally we would use the earliest of the bugs, but in this case, I >> don't think it matters, so I have no problem with your using the one you >> chose. >> >> @tomsontom Since you were the one who filed >> [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's >> currently assigned to you, do you want to be the second reviewer on this? > > @kevinrushforth I have a manual app that can perform a simple test to verify > that when a robot sends KeyCode.A through KeyCode.Z the system receives the > characters 'a' to 'z'. On the Mac this sanity test was failing on German and > French keyboards prior to these changes. The test is part of a key logger app > I created. > > I chose this bug because it has a straight-forward test attached and some > recent comment activity. > > @tomsontom Could you point me to the relevant code in Swing? I'm looking at > the code but am getting lost in the layers. https://github.com/openjdk/jdk/blob/8760688d213865eaf1bd675056eb809cdae67048/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m#L462 - PR: https://git.openjdk.java.net/jfx/pull/425
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assumes a US >> QWERTY layout). The new code first identifies a set of Mac keys which can >> produce different characters based on the user’s keyboard layout. A Mac key >> code outside that area is processed exactly as before. For a key inside the >> layout-sensitive area the code calls UCKeyTranslate to translate the key to >> an unshifted ASCII character based on the active keyboard and uses that to >> determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the >> old QWERTY mapping to find a candidate key. If it lies in the >> layout-sensitive area the code then scans the entire area calling >> UCKeyTranslate until it finds a match. If the key lies outside the >> layout-sensitive area it’s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications >> built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents >> with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z >> accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't >> take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard >> Layout (Y/Z) > > I see that the Windows pre-submit test build failed. It's clearly not related > to anything in this PR, so it can be ignored. > > I'll review this PR later (hopefully next week some time), but I have a > couple general comments: > > 1. Would it be possible to provide an automated test? Maybe not since it is > sensitive to the keyboard layout. > 2. For the related bugs, we can either close them as duplicates of this bug > or use the `/solves` command to list them here. Generally, we would do the > former in the case it really is a single fix, as this seems to be. That's > what I'll do once this bug is integrated unless there is a good reason not > to. Normally we would use the earliest of the bugs, but in this case, I don't > think it matters, so I have no problem with your using the one you chose. > > @tomsontom Since you were the one who filed > [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's > currently assigned to you, do you want to be the second reviewer on this? @kevinrushforth I have a manual app that can perform a simple test to verify that when a robot sends KeyCode.A through KeyCode.Z the system receives the characters 'a' to 'z'. On the Mac this sanity test was failing on German and French keyboards prior to these changes. The test is part of a key logger app I created. I chose this bug because it has a straight-forward test attached and some recent comment activity. @tomsontom Could you point me to the relevant code in Swing? I'm looking at the code but am getting lost in the layers. - PR: https://git.openjdk.java.net/jfx/pull/425
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Fri, 12 Mar 2021 16:27:27 GMT, Martin Fox wrote: > This PR adds code to ensure that KeyCodeCombinations match KeyEvents as > expected by more accurately mapping from a Mac key code to a Java key code > based on the user’s active keyboard layout (the existing code assumes a US > QWERTY layout). The new code first identifies a set of Mac keys which can > produce different characters based on the user’s keyboard layout. A Mac key > code outside that area is processed exactly as before. For a key inside the > layout-sensitive area the code calls UCKeyTranslate to translate the key to > an unshifted ASCII character based on the active keyboard and uses that to > determine the Java key code. > > When performing the reverse mapping for the Robot the code first uses the old > QWERTY mapping to find a candidate key. If it lies in the layout-sensitive > area the code then scans the entire area calling UCKeyTranslate until it > finds a match. If the key lies outside the layout-sensitive area it’s > processed exactly as before. > > There are multiple duplicates of these bugs logged against Mac applications > built with JavaFX. > > https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents > with alternative keyboard layouts > https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z > accelerator is not working with French keyboard > https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't > take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard > Layout (Y/Z) I see that the Windows pre-submit test build failed. It's clearly not related to anything in this PR, so it can be ignored. I'll review this PR later (hopefully next week some time), but I have a couple general comments: 1. Would it be possible to provide an automated test? Maybe not since it is sensitive to the keyboard layout. 2. For the related bugs, we can either close them as duplicates of this bug or use the `/solves` command to list them here. Generally, we would do the former in the case it really is a single fix, as this seems to be. That's what I'll do once this bug is integrated unless there is a good reason not to. Normally we would use the earliest of the bugs, but in this case, I don't think it matters, so I have no problem with your using the one you chose. @tomsontom Since you were the one who filed [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's currently assigned to you, do you want to be the second reviewer on this? - PR: https://git.openjdk.java.net/jfx/pull/425
Re: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v2]
> Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still > the real parent. > In that case, it doesn't get collected. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8263402 Added new verison of the unit-test - Changes: - all: https://git.openjdk.java.net/jfx/pull/424/files - new: https://git.openjdk.java.net/jfx/pull/424/files/7f7b4569..b39db419 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=424=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=424=00-01 Stats: 41 lines in 1 file changed: 15 ins; 23 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/424/head:pull/424 PR: https://git.openjdk.java.net/jfx/pull/424
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Fri, 12 Mar 2021 14:27:44 GMT, Florian Kirmaier
wrote:
>> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
>> line 96:
>>
>>> 94: } catch (Exception e) {
>>> 95: throw e;
>>> 96: }
>>
>> line 91: is non reachable code and second catch block is note required.
>
> Line 91 is reachable. Application.launch throws an IllegalStateException,
> even so, it doesn't declare it.
> I've Removed the second catch block.
At the time Ambarish made the comment, line 91 referred to this statement:
throw new Exception();
This is indeed not reachable (although the compiler can't tell that), since
`Assert.fail` unconditionally throws an `AssertionError`
-
PR: https://git.openjdk.java.net/jfx/pull/421
RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user’s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user’s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it’s processed exactly as before. There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) - Commit messages: - Mac - generate KeyCodes that match user's active keyboard layout. Changes: https://git.openjdk.java.net/jfx/pull/425/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=425=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8150709 Stats: 174 lines in 2 files changed: 172 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/425.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/425/head:pull/425 PR: https://git.openjdk.java.net/jfx/pull/425
Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
Hi Kevin, Unfortunately I don't have a test case. We are using various WebViews in our production application hence we don't know where/why exactly the application freezes. We were hoping that we will be able to identify it using the native debug build (& attached debugged) but it is now unfortunately crashing with the above error. Side note: Should I contact Arun directly or is he seeing these messages? -- PrimosK On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth wrote: > Arun should be able to help you with the crash you are seeing in debug > mode. > > Regarding the hang, do you have a test case that will reproduce it? A > few different developers have reported similar hangs. We ended up > closing a recently-filed bug, JDK-8260238 [1], because were (and still > are) unable to reproduce the hang. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8260238 > > > On 3/12/2021 1:06 AM, Primož Kokol wrote: > > Hi everyone, > > > > I would need some help related to OpenJFX build. > > > > I was able to successfully prepare a build following this procedure (from > > pull/417 request): > > https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 > > > > We wanted to use it in our existing application (Java 11.0.10) to debug > an > > issue where the application would hang/freeze for no obvious reason > because > > of WebKit. > > > > In order to use this build we've manually overridden javafx-*.jar files > in > > our application with the ones from the above build. > > We've also placed all produced DLL files in our application's "bin" > folder > > so they are properly picked up (I've verified and I can confirm that > > jfxwebkit.dll produced by our debug build is loaded). > > > > After using this native debug build, the application will crash instead > > with: > > Unhandled exception at 0x7FFA1E93286E (ucrtbase.dll) in java.exe: > Fatal > > program exit requested. > > > > It looks like it happens when JS code calls Java method. > > > > There is the call stack at the time when exception happens: > > > >> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. > >jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, > const > > char * __formal, int __formal) Line 672 C++ Symbols loaded. > > > > > jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM > > & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ > > Symbols loaded. > > > > > jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM > > & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. > >jfxwebkit.dll!JSC::jsDynamicCast > *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line > > 182 C++ Symbols loaded. > >jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, > const > > WTF::String & name, JSC::InternalFunction::NameAdditionMode > > nameAdditionMode) Line 49 C++ Symbols loaded. > >jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const > > WTF::String & ident) Line 58 C++ Symbols loaded. > >jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, > > const WTF::String & name) Line 231 C++ Symbols loaded. > >jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * > > globalObject, const WTF::String & name, JSC::Bindings::Method * method) > > Line 212 C++ Symbols loaded. > > > jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject > > * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols > loaded. > > > > > jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject > > * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) > > Line 124 C++ Symbols loaded. > >jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * > > globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. > >jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * > > globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols > loaded. > >jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, > > JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ > > Symbols loaded. > >jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * > > pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, > > JSC::JSValue baseValue, const JSC::Identifier & ident, > > JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. > >jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, > const > > JSC::Instruction * pc) Line 833 C++ Symbols loaded. > >jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. > >00c7ef8fae90() Unknown Non-user code > >00c7ef8faf50() Unknown Non-user code > >028d52eeedbb() Unknown Non-user code > >() Unknown Non-user code > >028d52eeedb6() Unknown Non-user code > > > > ... and partial output from the output console: > > > >
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assumes a US >> QWERTY layout). The new code first identifies a set of Mac keys which can >> produce different characters based on the user’s keyboard layout. A Mac key >> code outside that area is processed exactly as before. For a key inside the >> layout-sensitive area the code calls UCKeyTranslate to translate the key to >> an unshifted ASCII character based on the active keyboard and uses that to >> determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the >> old QWERTY mapping to find a candidate key. If it lies in the >> layout-sensitive area the code then scans the entire area calling >> UCKeyTranslate until it finds a match. If the key lies outside the >> layout-sensitive area it’s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications >> built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents >> with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z >> accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't >> take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard >> Layout (Y/Z) > > I see that the Windows pre-submit test build failed. It's clearly not related > to anything in this PR, so it can be ignored. > > I'll review this PR later (hopefully next week some time), but I have a > couple general comments: > > 1. Would it be possible to provide an automated test? Maybe not since it is > sensitive to the keyboard layout. > 2. For the related bugs, we can either close them as duplicates of this bug > or use the `/solves` command to list them here. Generally, we would do the > former in the case it really is a single fix, as this seems to be. That's > what I'll do once this bug is integrated unless there is a good reason not > to. Normally we would use the earliest of the bugs, but in this case, I don't > think it matters, so I have no problem with your using the one you chose. > > @tomsontom Since you were the one who filed > [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's > currently assigned to you, do you want to be the second reviewer on this? Sure I started looking into this last week and found the place this translation is done in swing (there it is done differently but only works for keys a-z but not for other chars like #,...) - PR: https://git.openjdk.java.net/jfx/pull/425
Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
Arun should be able to help you with the crash you are seeing in debug mode. Regarding the hang, do you have a test case that will reproduce it? A few different developers have reported similar hangs. We ended up closing a recently-filed bug, JDK-8260238 [1], because were (and still are) unable to reproduce the hang. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8260238 On 3/12/2021 1:06 AM, Primož Kokol wrote: Hi everyone, I would need some help related to OpenJFX build. I was able to successfully prepare a build following this procedure (from pull/417 request): https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 We wanted to use it in our existing application (Java 11.0.10) to debug an issue where the application would hang/freeze for no obvious reason because of WebKit. In order to use this build we've manually overridden javafx-*.jar files in our application with the ones from the above build. We've also placed all produced DLL files in our application's "bin" folder so they are properly picked up (I've verified and I can confirm that jfxwebkit.dll produced by our debug build is loaded). After using this native debug build, the application will crash instead with: Unhandled exception at 0x7FFA1E93286E (ucrtbase.dll) in java.exe: Fatal program exit requested. It looks like it happens when JS code calls Java method. There is the call stack at the time when exception happens: ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ Symbols loaded. jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. jfxwebkit.dll!JSC::jsDynamicCast(JSC::VM & vm, JSC::InternalFunction * from) Line 182 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 00c7ef8fae90() Unknown Non-user code 00c7ef8faf50() Unknown Non-user code 028d52eeedbb() Unknown Non-user code () Unknown Non-user code 028d52eeedb6() Unknown Non-user code ... and partial output from the output console: (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as fi(x)ed, (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, (t)transformed ancestor Dirty (z)-lists, Dirty (n)ormal flow lists Traversal needs: requirements (t)raversal on descendants, (b)acking or hierarchy traversal on descendants, (r)equirements traversal on all descendants, requirements traversal on all (s)ubsequent layers, (h)ierarchy traversal on all descendants, update of paint (o)rder children Update needs:post-(l)ayout requirements, (g)eometry, (k)ids geometry, (c)onfig, layer conne(x)ion, (s)crolling tree Scrolling scope: box contents
Re: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v2]
On Fri, 12 Mar 2021 07:55:54 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8263402
>> Added new verison of the unit-test
>
> tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line
> 106:
>
>> 104: });
>> 105: }
>> 106: }
>
> In order to make this test similar to existing system tests, I made some
> relevant changes. Modified test is added below.
> The modified test fails with this fix, but I expected it to pass. Can you
> please check this.
>
> Changes are
> 1. `Thread.sleep()` is removed.
> 2. `root` and `toBeRemoved` button are now class members.
> 3. Scenegraph is constructed and shown in `TestApp.start()` method.
>
>
> public class StyleMemoryLeakTest {
>
> static CountDownLatch startupLatch;
> static Stage stage;
> static Button toBeRemoved;
> static Group root;
>
> public static class TestApp extends Application {
>
> @Override
> public void start(Stage primaryStage) throws Exception {
> stage = primaryStage;
> toBeRemoved = new Button();
> root = new Group();
> root.getChildren().add(toBeRemoved);
> stage.setScene(new Scene(root));
> stage.setOnShown(l -> {
> Platform.runLater(() -> startupLatch.countDown());
> });
> stage.show();
> }
> }
>
> @BeforeClass
> public static void initFX() throws Exception {
> startupLatch = new CountDownLatch(1);
> new Thread(() ->
> Application.launch(StyleMemoryLeakTest.TestApp.class,
> (String[])null)).start();
> assertTrue("Timeout waiting for FX runtime to start",
> startupLatch.await(15, TimeUnit.SECONDS));
> }
>
> @Test
> public void testRootNodeMemoryLeak() throws Exception {
> Util.runAndWait(() -> {
> root.getChildren().clear();
> stage.hide();
> });
> JMemoryBuddy.memoryTest((checker) -> {
> checker.assertCollectable(stage);
> checker.setAsReferenced(toBeRemoved);
> stage = null;
> });
> }
>
> @AfterClass
> public static void teardownOnce() {
> Platform.runLater(() -> {
> Platform.exit();
> });
> }
> }
I've added your verison of the unit-test. You forgot `root = null;` which was
why the test failed.
If I would rewrite the test, I would put everything into the TestMethod.
Because this way it's not necessary to set all the class-variables to null. It
also wouldn't reuse the Stage of the Application. The scope of the test would
be much smaller, because the actual test and the initialization of JavaFX would
be separated.
Should I change it that way?
-
PR: https://git.openjdk.java.net/jfx/pull/424
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Wed, 10 Mar 2021 23:02:07 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXStartupTest.java
> line 46:
>
>> 44:
>> 45: @Test (timeout = 15000)
>> 46: public void testStartupThenLaunch() throws Exception {
>
> It will be more robust for these two test methods to be in separate files.
> Otherwise they might interfere with each other. If
> `testStartupThenLaunchInFX` runs first, then an error in that test (e.g., if
> the fix isn't applied and it times out) will cause the
> `testStartupThenLaunch` to fail. Conversely, if `testStartupThenLaunch` runs
> first, then the system is in a state where the Application has already been
> started by the time `testStartupThenLaunchInFX` runs. It will still pass, but
> won't be a solid test of the fix, since that case would fail today.
They are seperated now!
> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java
> line 46:
>
>> 44:
>> 45: @Test (timeout = 15000)
>> 46: public void testStartupThenLaunch() throws Exception {
>
> It will be more robust for these two test methods to be in separate files.
> Otherwise they might interfere with each other.
They are seperated now!
-
PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Fri, 12 Mar 2021 14:31:17 GMT, Florian Kirmaier
wrote:
>> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
>> line 80:
>>
>>> 78: System.out.println("Finished launch!");
>>> 79: Assert.fail("Error: No Exception was thrown - expected
>>> IllegalStateException");
>>> 80: } catch (IllegalStateException e) {
>>
>> Maybe add a comment that this exception is expected?
>
> I've added a comment and a print-statement that this is expected - on both
> catches for EllegalStateException
The comment looks fine. See my global comment about the print statement.
-
PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Fri, 12 Mar 2021 11:52:24 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one >> additional commit since the last revision: >> >> JDK-8263322 >> updated the javadoc to mention the new case. > > Suggested minor changes. I've seperated the tests now in seperated files! Now all the changes requested should be in the PR. - PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v7]
On Fri, 12 Mar 2021 14:49:41 GMT, Florian Kirmaier
wrote:
>> Fixing deadlock when calling Application.launch in the FXThread after
>> Platform.startup
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8263322
> Seperated the unit-tests into seperate files
Thanks for splitting up the tests. I ran them with the fix and all pass, I then
ran them without the fix and only the one I expected to fail did.
Before approving this, can you change the title of the JBS bug and CSR issue to
match (after doing that you will also need to update this PR title) as
recommended in the CSR? My suggestion is something like:
Calling Application.launch on FX thread should throw IllegalStateException, but
causes deadlock
Another thing I recommend is to comment out or remove the print statements in
the tests. They are useful while debugging, but in production we prefer tests
to only print something as a warning or error.
I also left a few inline comments.
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
line 35:
> 33: public class InitializeJavaFXBase {
> 34:
> 35:
Minor: there is an extra blank line here
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchBase.java
line 22:
> 20: Application.launch(InitializeApp.class);
> 21: }).start();
> 22: appLatch.await(5, TimeUnit.SECONDS);
You should `assertTrue` the return value of `await`.
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXStartupBase.java
line 15:
> 13: latch.countDown();
> 14: });
> 15: latch.await(5, TimeUnit.SECONDS);
You should `assertTrue` the return value of `await`.
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunch1Test.java
line 41:
> 39:
> 40: @Test (timeout = 15000)
> 41: public void testStartupThenLaunchInFX() throws Exception {
Would something like `testLaunchThenLaunchInFX` be a better name? As it is, it
uses the same name as the test that really does use `Platform.startup` which I
found confusing.
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunch2Test.java
line 41:
> 39:
> 40: @Test (timeout = 15000)
> 41: public void testStartupThenLaunch() throws Exception {
Would something like `testLaunchThenLaunch` be a better name?
-
PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v6]
> Fixing deadlock when calling Application.launch in the FXThread after > Platform.startup Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: - JDK-8263322 Small changes based on codereview - JDK-8263322 Some small cleanups based on codereview - Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/145ae592..92e0fca6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=421=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx=421=04-05 Stats: 7 lines in 1 file changed: 3 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene
On Thu, 11 Mar 2021 21:58:40 GMT, Kevin Rushforth wrote: >> Since this touches CSS, it needs a second reviewer. > > I think others can review this. I do have a couple questions: > 1. In general, I don't like the idea of just making everything a weak > reference, since it often masks a design issue. Two exceptions are for caches > and for back references to a "parent" or controlling object that has a strong > reference to "this" object (most of our weak listeners fall into this latter > pattern). It sounds like latter case also applies here. Can you confirm that? > 2. Have you verified that all the places that use the fields that are now > WeakReferences are prepared to deal with `get()` returning a null object? About whether we should use WeakReference here or not. It definitely falls into the exception for referring to the Parrent of a Node. (Or to the Parent in a more abstract sense, I think it can also be the parent of the parent, or even from another SceneGraph.) I don't know the CSS code very well, so I currently don't have the knowledge how to change it. But if we would change this variable, whenever the node is removed from the SceneGraph, my concern would be that it would have an unfavorable complexity. Currently (I hope) the complexity of removing a Node from the SceneGraph is O(1). If we would remove the stylehelper from the node, then the complexity would be O(). The current change assumes that we don't process the CSS, when a node is removed from the SG. This is why it isn't checked for null. I would argue, if this causes an Error, then it just reveals another issue, which would be preferable over a more complicated fix, and also changing the complexity of removing nodes from the SG. - PR: https://git.openjdk.java.net/jfx/pull/424
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Fri, 12 Mar 2021 09:01:49 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java
> line 2:
>
>> 1: /*
>> 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights
>> reserved.
>
> Minor year correction-> `Copyright (c) 2021,`
> Similar change in other test files.
Done, so it's the year where changes happened, ok!
> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
> line 96:
>
>> 94: } catch (Exception e) {
>> 95: throw e;
>> 96: }
>
> line 91: is non reachable code and second catch block is note required.
Line 91 is reachable. Application.launch throws an IllegalStateException, even
so, it doesn't declare it.
I've Removed the second catch block.
> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
> line 33:
>
>> 31: import junit.framework.Assert;
>> 32: import org.junit.BeforeClass;
>> 33: import org.junit.Test;
>
> unused imports, BeforeClass and Test.
removed!
-
PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Wed, 10 Mar 2021 23:10:06 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
> line 80:
>
>> 78: System.out.println("Finished launch!");
>> 79: Assert.fail("Error: No Exception was thrown - expected
>> IllegalStateException");
>> 80: } catch (IllegalStateException e) {
>
> Maybe add a comment that this exception is expected?
I've added a comment and a print-statement that this is expected - on both
catches for EllegalStateException
-
PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v7]
> Fixing deadlock when calling Application.launch in the FXThread after > Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 Seperated the unit-tests into seperate files - Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/92e0fca6..a73bcf82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=421=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx=421=05-06 Stats: 351 lines in 9 files changed: 221 ins; 130 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v5]
> Fixing deadlock when calling Application.launch in the FXThread after > Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 fixed the copyright headers, based on codereview - Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/c16b6067..145ae592 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=421=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=421=03-04 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8261840: Submenus close to screen borders are no longer repositioned
On Fri, 12 Mar 2021 10:03:53 GMT, Ajit Ghaisas wrote: >> Reverting to the old way of showing the context menu but with application >> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct >> size measurement of the menu. > > Marked as reviewed by aghaisas (Reviewer). This fixes the bug in question, although I see a slight regression in behavior on Windows with 125% pixel scaling (it doesn't reproduce with any other scaling value that I tried). With the original test case for [JDK-8228363](https://bugs.openjdk.java.net/browse/JDK-8228363), and `TOP` as the value of `side`, the initial menu is positioned slightly lower (by a few pixels) than it should be. See the attached image. It is correct the second and subsequent times the context menu is opened. Given that this new bug only happens with 125% scaling, it seems likely that it is a preexisting bug, and this fix merely exposes it. Can you take a look at this? If it is preexisting, then we should file a follow-on bug for this.  - PR: https://git.openjdk.java.net/jfx/pull/410
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier
wrote:
>> Fixing deadlock when calling Application.launch in the FXThread after
>> Platform.startup
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8263322
> updated the javadoc to mention the new case.
Suggested minor changes.
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
line 96:
> 94: } catch (Exception e) {
> 95: throw e;
> 96: }
line 91: is non reachable code and second catch block is note required.
tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
line 33:
> 31: import junit.framework.Assert;
> 32: import org.junit.BeforeClass;
> 33: import org.junit.Test;
unused imports, BeforeClass and Test.
-
PR: https://git.openjdk.java.net/jfx/pull/421
Re: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene
On Wed, 10 Mar 2021 22:25:32 GMT, Florian Kirmaier wrote: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still > the real parent. > In that case, it doesn't get collected. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 180: > 178: helper.cacheContainer = new CacheContainer(node, styleMap, > depth); > 179: > 180: helper.firstStyleableAncestor = new > WeakReference<>(findFirstStyleableAncestor(node)); Can you investigate for an alternative to set `firstStyleableAncestor` to null when the related `node` is removed from scenegraph or may be `null` the reference to `Node.styleHelper` itself when Node is removed from scenegraph. This will result in recreating the `Node.styleHelper` next time when it is added back to scenegraph. - PR: https://git.openjdk.java.net/jfx/pull/424
Re: RFR: 8261840: Submenus close to screen borders are no longer repositioned
On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger wrote: > Reverting to the old way of showing the context menu but with application > of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct > size measurement of the menu. Marked as reviewed by aghaisas (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/410
OpenJFX custom build - Java application crash (semi-related to 8262276)
Hi everyone, I would need some help related to OpenJFX build. I was able to successfully prepare a build following this procedure (from pull/417 request): https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 We wanted to use it in our existing application (Java 11.0.10) to debug an issue where the application would hang/freeze for no obvious reason because of WebKit. In order to use this build we've manually overridden javafx-*.jar files in our application with the ones from the above build. We've also placed all produced DLL files in our application's "bin" folder so they are properly picked up (I've verified and I can confirm that jfxwebkit.dll produced by our debug build is loaded). After using this native debug build, the application will crash instead with: Unhandled exception at 0x7FFA1E93286E (ucrtbase.dll) in java.exe: Fatal program exit requested. It looks like it happens when JS code calls Java method. There is the call stack at the time when exception happens: > ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ Symbols loaded. jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. jfxwebkit.dll!JSC::jsDynamicCast(JSC::VM & vm, JSC::InternalFunction * from) Line 182 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 00c7ef8fae90() Unknown Non-user code 00c7ef8faf50() Unknown Non-user code 028d52eeedbb() Unknown Non-user code () Unknown Non-user code 028d52eeedb6() Unknown Non-user code ... and partial output from the output console: (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as fi(x)ed, (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, (t)transformed ancestor Dirty (z)-lists, Dirty (n)ormal flow lists Traversal needs: requirements (t)raversal on descendants, (b)acking or hierarchy traversal on descendants, (r)equirements traversal on all descendants, requirements traversal on all (s)ubsequent layers, (h)ierarchy traversal on all descendants, update of paint (o)rder children Update needs:post-(l)ayout requirements, (g)eometry, (k)ids geometry, (c)onfig, layer conne(x)ion, (s)crolling tree Scrolling scope: box contents S-- -- -- -s 34 34 028D98F22260 (0,0) width=460 height=650 RenderView 0x28d4d4d1cd0 S-- -- -- -- 34 34 + 028D4D98D430 (0,0) width= no compositing work to do FrameView 028D4F2A4CF0 performPostLayoutTasks FrameView 028D4F2A4CF0 updateLayoutViewport() totalContentSize width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 header height 0 footer height 0 fixed behavior 0
Re: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4]
On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after >> Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one > additional commit since the last revision: > > JDK-8263322 > updated the javadoc to mention the new case. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights > reserved. Minor year correction-> `Copyright (c) 2021,` Similar change in other test files. - PR: https://git.openjdk.java.net/jfx/pull/421
