Re: Streaming short pieces of text into a textarea causes a crash

[John Hendrikx]

FX doesn't always warn you (as it would mean putting thread checks 
everywhere).


The first trace however shows that the change to the TextArea did not 
originate from the FX thread.


--John

On 19/12/2023 18:17, Frank Delporte wrote:
Thanks John, quick test with this change indeed seems to solve the 
problem!

Platform.runLater(() -> searchAction.appendAnswer(token));
I totally missed this and I didn't notice anything in the logs that 
was pointing in this direction.


Best regards
Frank Delporte

/Want to have coding-fun? /
/Check my blog //https://webtechie.be// /and 
book "Getting started with Java on Raspberry Pi" on 
//https://webtechie.be/books// 






 On Tue, 19 Dec 2023 09:14:51 +0100 *Frank Delporte 
* wrote ---


Hi, while experimenting with a ChatGPT-like user interface, I
found a crashing JVM with different types of errors when
streaming the response towards a TextArea. This is probably
caused by too fast refreshes of the text as pieces of content
are received within the same milliseconds:

19/12/2023 08:51:57.874 | DocsAnswerService  
| onNext   | INFO | Appending ' better'
19/12/2023 08:51:57.874 | DocsAnswerService  
| onNext   | INFO | Appending ' performance'
19/12/2023 08:51:57.875 | DocsAnswerService  
| onNext   | INFO | Appending ' after'
19/12/2023 08:51:57.978 | DocsAnswerService  
| onNext   | INFO | Appending ' the'
19/12/2023 08:51:57.979 | DocsAnswerService  
| onNext   | INFO | Appending ' first'
19/12/2023 08:51:57.979 | DocsAnswerService  
| onNext   | INFO | Appending ' and'

But even when collecting this pieces of text to e.g. minimum
255 characters to reduce the number of TextArea changes,
errors happen. So it's not clear how to prevent this as I
can't define the threshold to be used...

Dummy code causing the crash:

public class SearchAction {
    private final StringProperty answer;
    ...
    public StringProperty getAnswerProperty() {
    return answer;
    }

    public void appendAnswer(String token) {
this.answer.set(this.answer.getValue() + token);
    }
}

TextArea lastAnswer = new TextArea();
lastAnswer.textProperty().bind(searchAction.getAnswerProperty());

StreamingResponseHandler streamingResponseHandler =
new StreamingResponseHandler<>() {
    @Override
    public void onNext(String token) {
searchAction.appendAnswer(token);
    }
}

*Fatal Error *

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x00013f53b630, pid=13013, tid=80715
#
# JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA
(21.0.1+12) (build 21.0.1+12-LTS)
# Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA
(21.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops,
compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# j

javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576
javafx.graphics@21.0.1
#
# No core dump will be written. Core dumps have been disabled.
To enable core dumping, try "ulimit -c unlimited" before
starting Java again
#
# An error report file with more information is saved as:
# /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log
Exception in thread "JavaFX Application Thread"
java.lang.StackOverflowError: Delayed StackOverflowError due
to ReservedStackAccess annotated method
at

javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native
Method)
at

javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816)
at

javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004)
at

javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847)
at

javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113)
at

javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)
at
javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961)
at
javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466)
at

javafx

Re: RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView [v2]

[Andy Goryachev]

On Mon, 18 Dec 2023 15:51:01 GMT, Jose Pereda  wrote:

>> This PR fixes an issue when a new `TableColumn` is added to a `TableView` 
>> control with fixed cell size set, where the `TableRowSkinBase` failed to add 
>> the cells for the new column.
>> 
>> A test is included that fails before applying this PR and passes with it.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address feedback

verified the fix with the SCEE in the ticket as well as with additional manual 
tests in the MonkeyTester.
looks good on macOS 14.1.2

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1308#pullrequestreview-1789526626

Re: [External] : Re: New API: Animation/Timeline improvement

[Andy Goryachev]

You are right: the weak references are not suitable in this case.

These cases are clearly bugs in the skins, we should log them (unless already 
logged); I don’t think we need new APIs.

See

https://bugs.openjdk.org/issues/?jql=text%20~%20%22skin%20cleanup%22%20AND%20project%20%3D%20JDK%20AND%20component%20%3D%20javafx%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20%20DESC

There is an umbrella task

https://bugs.openjdk.org/browse/JDK-8241364

which collects all these issues.
Care to create JBS tickets?

Thanks!
-andy



From: John Hendrikx 
Date: Monday, December 18, 2023 at 16:14
To: Andy Goryachev , openjfx-dev 

Subject: [External] : Re: New API: Animation/Timeline improvement

I don't think that's the correct solution, as it opens up a whole new avenue 
for subtle bugs, bringing GC/JVM/OS whims and settings into the mix. We want 
the clean-up to be easier to reason about, not harder.

Even if it were a good idea, it's likely also going to be a breaking change to 
add weak references at this stage, without some kind of opt-in (which would 
then require new API, in which case we might as well go for a solution that has 
no need of weak references).

I feel I have to keep repeating this, but there almost zero guarantees made by 
the JVM or Java with regards to references; they are fine for internal 
processes carefully designed to have no user visible side effects, but 
burdening the user with side effects (delayed clean-up, or early unexpected 
clean-up due to lack of a hard reference) without the user actually choosing to 
use a reference type themselves is not a good design.

--John
On 18/12/2023 17:18, Andy Goryachev wrote:
Would making Timeline to use WeakReferences solve the issue without the need 
for a new API?

-andy



From: openjfx-dev 
 on behalf 
of John Hendrikx 
Date: Friday, December 15, 2023 at 21:53
To: openjfx-dev 
Subject: New API: Animation/Timeline improvement
Hi list,

I've noticed that Animations and Timelines are often a source of leaks,
and their clean-up is often either non-existent or incorrect.  The
reason they cause leaks easily is because a running animation or
timeline is globally referred from a singleton PrimaryTimer.  The
animation or timeline then refers to properties or event handlers which
refer to controls (which refer to parents and the entire scene).

For example:

- ScrollBarBehavior uses a Timeline, but neglects to clean it up.  If it
was running at the time a Scene is detached from a Window, and that
Scene is left to go out of scope, it won't because Timeline refers it;
this can happen if the behavior never receives a key released event.

- ScrollBarBehavior has no dispose method overridden, so swapping Skins
while the animation is running will leave a Timeline active (it uses
Animation.INDEFINITE)

- SpinnerBehavior has flawed clean up; it attaches a Scene listener and
disables its timeline when the scene changed, but the scene doesn't have
to change for it to go out of scope as a whole... Result is that if you
have a spinner timeline running, and you close the entire window (no
Scene change happens), the entire Scene will still be referred.  It also
uses an indefinite cycle count.  It also lacks a dispose method, so
swapping Skins at a bad moment can also leave a reference.

I think these mistakes are common, and far too easy to make.  The most
common use cases for animations revolve around modifying properties on
visible controls, and although animations can be used for purposes other
than animating UI controls, this is extremely rare.  So it is safe to
say that in 99% of cases you want the animation to stop once a some Node
is no longer showing. For both the mentioned buggy behaviors above, this
would be perfect.  A spinner stops spinning when no longer showing, and
a scroll bar stops scrolling when no longer showing.  It is also likely
to apply for many other uses of timelines and animations.

I therefore want to propose a new API, either on Node or Animation (or
both):

 /**
  * Creates a new timeline which is stopped automatically when this Node
  * is no longer showing. Stopping timelines is essential as they
may refer
  * nodes even after they are no longer used anywhere, preventing
them from
  * being garbage collected.
  */
 Node.createTimeline();  // and variants with the various Timeline
constructors

And/or:

 /**
  * Links this Animation to the given Node, and stops the animation
  * automatically when the Node is no longer showing. Stopping
animations
  * is essential as they may refer nodes even after they are no
longer used
  * anywhere, preventing them from being garbage collected.
  */
 void stopWhenHidden(Node node);

The above API for Animation could also be provided through another
constructor, which takes a Node which will it be linked to.

Alternatives:

- Be a lo

Re: Streaming short pieces of text into a textarea causes a crash

[Frank Delporte]

Thanks John, quick test with this change indeed seems to solve the problem!

Platform.runLater(() -> searchAction.appendAnswer(token));

I totally missed this and I didn't notice anything in the logs that was 
pointing in this direction.



Best regards

Frank Delporte




Want to have coding-fun? 

Check my blog https://webtechie.be/ and book "Getting started with Java on 
Raspberry Pi" on https://webtechie.be/books/













 On Tue, 19 Dec 2023 09:14:51 +0100 Frank Delporte  
wrote ---



Hi, while experimenting with a ChatGPT-like user interface, I found a crashing 
JVM with different types of errors when streaming the response towards a 
TextArea. This is probably caused by too fast refreshes of the text as pieces 
of content are received within the same milliseconds:



19/12/2023 08:51:57.874 | DocsAnswerService   | onNext  
 | INFO | Appending ' better'

19/12/2023 08:51:57.874 | DocsAnswerService   | onNext  
 | INFO | Appending ' performance'

19/12/2023 08:51:57.875 | DocsAnswerService   | onNext  
 | INFO | Appending ' after'

19/12/2023 08:51:57.978 | DocsAnswerService   | onNext  
 | INFO | Appending ' the'

19/12/2023 08:51:57.979 | DocsAnswerService   | onNext  
 | INFO | Appending ' first'

19/12/2023 08:51:57.979 | DocsAnswerService   | onNext  
 | INFO | Appending ' and'



But even when collecting this pieces of text to e.g. minimum 255 characters to 
reduce the number of TextArea changes, errors happen. So it's not clear how to 
prevent this as I can't define the threshold to be used...



Dummy code causing the crash:



public class SearchAction {

    private final StringProperty answer;

    ...

    public StringProperty getAnswerProperty() {

    return answer;

    }



    public void appendAnswer(String token) {

    this.answer.set(this.answer.getValue() + token);

    }

}



TextArea lastAnswer = new TextArea();

lastAnswer.textProperty().bind(searchAction.getAnswerProperty());



StreamingResponseHandler streamingResponseHandler = new 
StreamingResponseHandler<>() {

    @Override

    public void onNext(String token) {

    searchAction.appendAnswer(token);

    }

}



Fatal Error 



#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGBUS (0xa) at pc=0x00013f53b630, pid=13013, tid=80715

#

# JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA (21.0.1+12) (build 
21.0.1+12-LTS)

# Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA (21.0.1+12-LTS, mixed mode, 
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)

# Problematic frame:

# j  
javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576
 javafx.graphics@21.0.1

#

# No core dump will be written. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting Java again

#

# An error report file with more information is saved as:

# /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log

Exception in thread "JavaFX Application Thread" java.lang.StackOverflowError: 
Delayed StackOverflowError due to ReservedStackAccess annotated method

at 
javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native
 Method)

at 
javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816)

at 
javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004)

at 
javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847)

at 
javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113)

at 
javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)

at javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961)

at javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466)

at 
javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110)

at 
javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145)

at 
javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50)

at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444)

at 
javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347)

at 
javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$2(LambdaMultiplePropertyChangeListenerHandler.java:95)

at 
javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:82)

at 
javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360)

at 
javafx.base/com.sun.javafx.binding.ExpressionHelper.fire

Re: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4]

[John Hendrikx]

On Tue, 19 Dec 2023 12:24:14 GMT, Johan Vos  wrote:

> As for the memory leak issue: there were several. The first commit in this PR 
> fixed a clear memory leak, but the one that is still left is not described in 
> the issue. It occurs because whenever the SystemMenuBar is shown after it was 
> not shown, all MenuItems will be readded using `GlassSystemMenu.setMenu`. 
> This will invoke `GlassSystemMenu.insertMenuItem(... MenuItemBase 
> menuItem...)` Inside this method, platform-specific menuItems will be 
> created, that will adapt when the `MenuItemBase` properties are changing. The 
> annoying thing, as stated in the first comment of that method, is that we 
> don't know if the passed `MenuItemBase` instance was previously used in this 
> method (in which case the listeners are regisered to this instance) or not. 
> That is why for example the `visibilityListener` is unconditionally removed 
> (even if we don't know if it was ever added) and then added. We can do the 
> same for the other properties (preventing the use of weak listeners), but it 
> would be nice if we
  could address this case using the api introduced in the deterministic 
listeners management (I would very much prefer that over weak listeners). I'm 
not too familiar with the new API though, but it seems difficult to do this 
_inside_ this method, as we would still add a listener each time the method is 
invoked with an item that already has a listener registered?

It's still a bit unclear for me.  So what I write below may be off the mark.

>From what I can see, `setMenus` will first remove all items, then re-add them. 
> The `clearMenu` function seems like a logical place to remove listeners that 
>may be present.  The problem is where to keep track off the listeners.  I see 
>a few options:

1. Track the listeners in a few `Map`s in `GlassSystemMenu`, something like 
`Map`, with a different `Map` for each listener 
type (text, disabled, mnemonic, etc).  Or something more elaborate with a 
listener holder, nested maps, etc.

These maps can then iterated when `setMenus` is called to clear out ALL the 
listeners (or as part of `clearMenu`.

2. Similar to above but store the listener information in the properties of 
`Menu`

3. Using the new resource management system. Attach all listeners with a `when` 
condition based on a `SimpleBooleanProperty` that you **replace** each time 
`setMenus` is called (replacement is needed in this case as we don't know if 
the menus were used before or not, but it is still relatively clean).

The last one works like this:

Create a new non-final field: `BooleanProperty active`

In `setMenus` do:

  if (active != null) {
active.set(false);  // this releases all listeners attached with 
`when(active)`
  }

  active = new SimpleBooleanProperty(true);  // replace active with a new 
property, as we can't reuse it

Then attach all listeners conditionally like so:

  mb.textProprty().when(active).addListener( ... );

The idea here is that because `active` is a different property each time 
`setMenus` is called, all old listeners will be removed when active goes to 
`false`, and will be eligible for GC because the `active` property was also 
replaced (and the old one, which we just set to `false`, is not referenced 
anywhere anymore).

Illustration:

![image](https://github.com/openjdk/jfx/assets/995917/d5b67994-cab0-4743-a2d8-68127d5223af)

-

PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862755206

Re: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4]

[Johan Vos]

On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos  wrote:

>> A listener was added but never removed.
>> This patch removes the listener when the menu it links to is cleared. Fix 
>> for https://bugs.openjdk.org/browse/JDK-8319779
>
> Johan Vos has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix more memoryleaks due to listeners never being unregistered.

As for the memory leak issue: there were several. The first commit in this PR 
fixed a clear memory leak, but the one that is still left is not described in 
the issue. 
It occurs because whenever the SystemMenuBar is shown after it was not shown, 
all MenuItems will be readded using `GlassSystemMenu.setMenu`. This will invoke 
`GlassSystemMenu.insertMenuItem(... MenuItemBase menuItem...)` 
Inside this method, platform-specific menuItems will be created, that will 
adapt when the `MenuItemBase` properties are changing. The annoying thing, as 
stated in the first comment of that method, is that we don't know if the passed 
`MenuItemBase` instance was previously used in this method (in which case the 
listeners are regisered to this instance) or not. That is why for example the 
`visibilityListener` is unconditionally removed (even if we don't know if it 
was ever added) and then added. 
We can do the same for the other properties (preventing the use of weak 
listeners), but it would be nice if we could address this case using the api 
introduced in the deterministic listeners management (I would very much prefer 
that over weak listeners).
I'm not too familiar with the new API though, but it seems difficult to do this 
_inside_ this method, as we would still add a listener each time the method is 
invoked with an item that already has a listener registered?

-

PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862664763

Re: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4]

[Johan Vos]

On Tue, 19 Dec 2023 09:59:32 GMT, John Hendrikx  wrote:

>> Johan Vos has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fix more memoryleaks due to listeners never being unregistered.
>
> Would it be an idea to do deterministic clean-up?
> 
> The JIRA tickets involved are light on details, and I don't have a Mac, so I 
> can't test the leak (I think?), but it seems to me that you will want to 
> remove the listeners when the menu bar isn't visible (and re-add them if it 
> becomes visible again?).
> 
> From what I understand, these are normal JavaFX controls wrapped into 
> adapters, and so any listeners installed through the adapter interface will 
> end up on controls.  The `GlobalMenuAdapter` seems to be tracking the 
> `showing` property, and calls `show` / `hide` accordingly.
> 
> The ticket says:
> 
>> when an application loses focus, the SystemMenu is removed. When it gets 
>> focus again, the SystemMenu is "back".
> 
> My question is, is there any event that can be used to trigger clean-up when 
> this happens?  Do the controls go invisible, are they no longer showing (is 
> `hide` called?)  There must be something.  If there is something, then some 
> kind of disposal can be triggered for deterministic clean-up (ie. add 
> `dispose` method).
> 
> If you can go further and distill this information into a boolean property 
> then a pattern like this can be used:
> 
> mb.textProperty()
>  .when(showingProperty)  // assumes showing property becomes 
> false when focus is lost...
>  .addListener(valueModel -> glassMenu.setTitle(parseText(mb)));
> 
> The `showingProperty` can be fed from the hide/show event handlers to set it 
> to the right value, perhaps combined with focus information.

@hjohn You're absolutely right. It's another reason why I moved this PR to 
[WIP]. Instead of guessing and trying, I want to understand the deterministic 
path that leads to the issue with listeners being added and not removed. The 
one fixed in the first commit is clear, and well understood. Still, I saw 
uncollected listeners, with the GC root trace pointing to those other listeners 
(textProperty, mnemonicParsingProperty etc). Rather than trying to "fix" this 
with weak listeners, it is much better to find the real cause for this.
In the process of finding out, I'm adding a few shim classes and unit tests so 
that we can clearly test for regression.

-

PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862465132

Re: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4]

[John Hendrikx]

On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos  wrote:

>> A listener was added but never removed.
>> This patch removes the listener when the menu it links to is cleared. Fix 
>> for https://bugs.openjdk.org/browse/JDK-8319779
>
> Johan Vos has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix more memoryleaks due to listeners never being unregistered.

Would it be an idea to do deterministic clean-up?

The JIRA tickets involved are light on details, and I don't have a Mac, so I 
can't test the leak (I think?), but it seems to me that you will want to remove 
the listeners when the menu bar isn't visible (and re-add them if it becomes 
visible again?).

>From what I understand, these are normal JavaFX controls wrapped into 
>adapters, and so any listeners installed through the adapter interface will 
>end up on controls.  The `GlobalMenuAdapter` seems to be tracking the 
>`showing` property, and calls `show` / `hide` accordingly.

The ticket says:

> when an application loses focus, the SystemMenu is removed. When it gets 
> focus again, the SystemMenu is "back".

My question is, is there any event that can be used to trigger clean-up when 
this happens?  Do the controls go invisible, are they no longer showing (is 
`hide` called?)  There must be something.  If there is something, then some 
kind of disposal can be triggered for deterministic clean-up (ie. add `dispose` 
method).

If you can go further and distill this information into a boolean property then 
a pattern like this can be used:

mb.textProperty()
 .when(showingProperty)  // assumes showing property becomes false 
when focus is lost...
 .addListener(valueModel -> glassMenu.setTitle(parseText(mb)));

The `showingProperty` can be fed from the hide/show event handlers to set it to 
the right value, perhaps combined with focus information.

-

PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862456106

Re: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4]

[John Hendrikx]

On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos  wrote:

>> A listener was added but never removed.
>> This patch removes the listener when the menu it links to is cleared. Fix 
>> for https://bugs.openjdk.org/browse/JDK-8319779
>
> Johan Vos has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix more memoryleaks due to listeners never being unregistered.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java
 line 218:

> 216: mb.textProperty().addListener(new 
> WeakInvalidationListener(valueModel -> glassMenu.setTitle(parseText(mb;
> 217: mb.disableProperty().addListener(new 
> WeakInvalidationListener(valueModel -> 
> glassMenu.setEnabled(!mb.isDisable(;
> 218: mb.mnemonicParsingProperty().addListener(new 
> WeakInvalidationListener(valueModel -> glassMenu.setTitle(parseText(mb;

Isn't this the classic mistake being made with weak listeners where you are 
wrapping a listener, but then are not referring it?  The inner listener (which 
is created on the fly) is only weakly referenced, and so can be GC'd  
immediately.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1431137217

Re: Streaming short pieces of text into a textarea causes a crash

[John Hendrikx]

It looks like you are manipulating a property that is bound to a UI 
control on an external thread.


Property manipulations that are tied to controls that are part of an 
active (visible) Scene **must** be done on the FX thread.


Try:

    StreamingResponseHandler streamingResponseHandler = new 
StreamingResponseHandler<>() {

        @Override
    public void onNext(String token) {
    Platform.runLater(() -> 
searchAction.appendAnswer(token));

            }
    }

--John

On 19/12/2023 09:14, Frank Delporte wrote:


Hi, while experimenting with a ChatGPT-like user interface, I
found a crashing JVM with different types of errors when streaming
the response towards a TextArea. This is probably caused by too
fast refreshes of the text as pieces of content are received
within the same milliseconds:

19/12/2023 08:51:57.874 | DocsAnswerService   |
onNext   | INFO | Appending ' better'
19/12/2023 08:51:57.874 | DocsAnswerService   |
onNext   | INFO | Appending ' performance'
19/12/2023 08:51:57.875 | DocsAnswerService   |
onNext   | INFO | Appending ' after'
19/12/2023 08:51:57.978 | DocsAnswerService   |
onNext   | INFO | Appending ' the'
19/12/2023 08:51:57.979 | DocsAnswerService   |
onNext   | INFO | Appending ' first'
19/12/2023 08:51:57.979 | DocsAnswerService   |
onNext   | INFO | Appending ' and'

But even when collecting this pieces of text to e.g. minimum 255
characters to reduce the number of TextArea changes, errors
happen. So it's not clear how to prevent this as I can't define
the threshold to be used...

Dummy code causing the crash:

public class SearchAction {
    private final StringProperty answer;
    ...
    public StringProperty getAnswerProperty() {
    return answer;
    }

    public void appendAnswer(String token) {
    this.answer.set(this.answer.getValue() + token);
    }
}

TextArea lastAnswer = new TextArea();
lastAnswer.textProperty().bind(searchAction.getAnswerProperty());

StreamingResponseHandler streamingResponseHandler = new
StreamingResponseHandler<>() {
    @Override
    public void onNext(String token) {
    searchAction.appendAnswer(token);
    }
}

*Fatal Error *

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x00013f53b630, pid=13013, tid=80715
#
# JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA
(21.0.1+12) (build 21.0.1+12-LTS)
# Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA
(21.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops,
compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# j

javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576
javafx.graphics@21.0.1
#
# No core dump will be written. Core dumps have been disabled. To
enable core dumping, try "ulimit -c unlimited" before starting
Java again
#
# An error report file with more information is saved as:
# /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log
Exception in thread "JavaFX Application Thread"
java.lang.StackOverflowError: Delayed StackOverflowError due to
ReservedStackAccess annotated method
at

javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native
Method)
at

javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816)
at

javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004)
at

javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847)
at

javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113)
at

javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)
at
javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961)
at javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466)
at

javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110)
at

javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145)
at

javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50)
at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444)
at

javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347)
at

javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListen

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]

[Johan Vos]

On Mon, 18 Dec 2023 22:00:28 GMT, Kevin Rushforth  wrote:

> I did a build with GTK 3.22 (so it compiles the new code, does the dlsym, and 
> does the runtime check) and verified that there are no regressions when 
> running on an older system (Ubuntu 16.04).

That sounds good.

> If we decide that is a reasonable thing to do, we might want the minimum 
> _build-time_ version of GTK to be higher than the minimum version we support 
> at _runtime_.

That makes sense. We already do this with libc. When building (using the devkit 
based on the OpenJDK devkit), we use later versions of certain libraries, but 
we make sure the binaries still work on systems with older versions of the 
libraries. We should clearly state the minimum runtime requirements for some 
libraries (rather than for distributions, as it is always possible to hack new 
versions of libraries into old releases) .
What I really want to avoid is having 2 (or more) versions of the binaries for 
the same platform/arch/os combination.

-

PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1862376357

Re: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4]

[Johan Vos]

On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos  wrote:

>> A listener was added but never removed.
>> This patch removes the listener when the menu it links to is cleared. Fix 
>> for https://bugs.openjdk.org/browse/JDK-8319779
>
> Johan Vos has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix more memoryleaks due to listeners never being unregistered.

Moving this to [WIP] while I'm working on automated tests.

-

PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862311358

Streaming short pieces of text into a textarea causes a crash

[Frank Delporte]

Hi, while experimenting with a ChatGPT-like user interface, I found a crashing 
JVM with different types of errors when streaming the response towards a 
TextArea. This is probably caused by too fast refreshes of the text as pieces 
of content are received within the same milliseconds:



19/12/2023 08:51:57.874 | DocsAnswerService   | onNext  
 | INFO | Appending ' better'

19/12/2023 08:51:57.874 | DocsAnswerService   | onNext  
 | INFO | Appending ' performance'

19/12/2023 08:51:57.875 | DocsAnswerService   | onNext  
 | INFO | Appending ' after'

19/12/2023 08:51:57.978 | DocsAnswerService   | onNext  
 | INFO | Appending ' the'

19/12/2023 08:51:57.979 | DocsAnswerService   | onNext  
 | INFO | Appending ' first'

19/12/2023 08:51:57.979 | DocsAnswerService   | onNext  
 | INFO | Appending ' and'



But even when collecting this pieces of text to e.g. minimum 255 characters to 
reduce the number of TextArea changes, errors happen. So it's not clear how to 
prevent this as I can't define the threshold to be used...



Dummy code causing the crash:



public class SearchAction {

    private final StringProperty answer;

    ...

    public StringProperty getAnswerProperty() {

    return answer;

    }



    public void appendAnswer(String token) {

    this.answer.set(this.answer.getValue() + token);

    }

}



TextArea lastAnswer = new TextArea();

lastAnswer.textProperty().bind(searchAction.getAnswerProperty());



StreamingResponseHandler streamingResponseHandler = new 
StreamingResponseHandler<>() {

    @Override

    public void onNext(String token) {

    searchAction.appendAnswer(token);

    }

}



Fatal Error 



#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGBUS (0xa) at pc=0x00013f53b630, pid=13013, tid=80715

#

# JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA (21.0.1+12) (build 
21.0.1+12-LTS)

# Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA (21.0.1+12-LTS, mixed mode, 
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)

# Problematic frame:

# j  
javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576
 javafx.graphics@21.0.1

#

# No core dump will be written. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting Java again

#

# An error report file with more information is saved as:

# /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log

Exception in thread "JavaFX Application Thread" java.lang.StackOverflowError: 
Delayed StackOverflowError due to ReservedStackAccess annotated method

at 
javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native
 Method)

at 
javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816)

at 
javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004)

at 
javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847)

at 
javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113)

at 
javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)

at javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961)

at javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466)

at 
javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110)

at 
javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145)

at 
javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50)

at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444)

at 
javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347)

at 
javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$2(LambdaMultiplePropertyChangeListenerHandler.java:95)

at 
javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:82)

at 
javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360)

at 
javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)

at 
javafx.controls/javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1496)

at 
javafx.controls/javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1500)

at 
javafx.controls/javafx.scene.control.TextInputControl$TextProperty.controlContentHasChanged(TextInputControl.java:1439)

at 
javafx.controls/javafx.scene.control.TextInputControl.lambda$new$0(TextInputControl.java:176)

at