Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8271395: Crash during printing when disposing textures #618

Conversation

FlorianKirmaier
Copy link
Member

@FlorianKirmaier FlorianKirmaier commented Sep 6, 2021

This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
I'm open for better solutions on how to fix this Issue.
Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

  • JDK-8271395: Crash during printing when disposing textures

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx pull/618/head:pull/618
$ git checkout pull/618

Update a local copy of the PR:
$ git checkout pull/618
$ git pull https://git.openjdk.org/jfx pull/618/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 618

View PR using the GUI difftool:
$ git pr show -t 618

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/618.diff

Switching to the QuantumThread fixes the native crash when cleaning Textures.
@bridgekeeper
Copy link

bridgekeeper bot commented Sep 6, 2021

👋 Welcome back fkirmaier! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Ready for review label Sep 6, 2021
@FlorianKirmaier FlorianKirmaier changed the title 8271395 Fixing crash at printing 8271395: Fixing crash at printing Sep 6, 2021
@mlbridge
Copy link

mlbridge bot commented Sep 6, 2021

Webrevs

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't reviewed the approach yet. Presuming the approach is the right one, the implementation will need some refactoring to move the toolkit-specific logic into the toolkit. I'll provide more feedback when I go to review this.

@kevinrushforth
Copy link
Member

/reviewers 2

@openjdk
Copy link

openjdk bot commented Sep 6, 2021

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

@kevinrushforth kevinrushforth self-requested a review September 7, 2021 18:13
QuantumRenderer is no longer public
@christianheilmann
Copy link
Contributor

How to proceed to get this PR reviewed?

@@ -126,6 +128,10 @@ public static void disposeRecord(Disposer.Record rec) {
* thread on which the resources were created).
*/
public static void cleanUp() {
if (!Thread.currentThread().getName().startsWith("QuantumRenderer")) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seemed like a dubious way to detect the render thread so I looked around for how it is done elsewhere but instead I found
com/sun/javafx/sg/prism/NGCanvas.java
private static void runOnRenderThread(final Runnable r) {
// We really need a standard mechanism to detect the render thread !
if (Thread.currentThread().getName().startsWith("QuantumRenderer")) {

And .. it is also used by printing, and I added it in 2013 :-(

In my defence I copied the code from webview as mentioned in https://bugs.openjdk.org/browse/JDK-8094524

oh well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Phil, for digging into this. I was going to question it as well.

I'll file a follow-on bug to add such a method (not super urgent, but it would be worth having a consistent way to do this). I see that I suggested filing such an issue in the JBS issue Phil pointed to, but didn't do it.

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inline

@@ -126,6 +128,10 @@ public static void disposeRecord(Disposer.Record rec) {
* thread on which the resources were created).
*/
public static void cleanUp() {
if (!Thread.currentThread().getName().startsWith("QuantumRenderer")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Phil, for digging into this. I was going to question it as well.

I'll file a follow-on bug to add such a method (not super urgent, but it would be worth having a consistent way to do this). I see that I suggested filing such an issue in the JBS issue Phil pointed to, but didn't do it.

public static void runInRenderThreadAndWait(Runnable runnable) {
try {
CountDownLatch latch = new CountDownLatch(1);
com.sun.javafx.tk.quantum.QuantumRenderer.getInstance().execute(() -> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: this is in the same package, so you don't need the full package name. As long as you are making other changes, you might change this, too.

A bigger question is that I think this is the first time we've used execute directly. I'm not sure that's a problem, but want to take a second look at it. The other places where we run a job on the renderer all use Toolkit.getToolkit(). addRenderJob(), which ultimately calls submit().

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the package prefix.

I've just tested it, and the method "submit" is changed by overriding newTaskFor in QuantumRenderer. This has the effect, that calling submit leads to an exception. But calling execute works.

changes based on codereview
We now catch Throwable instead of Exception
@FlorianKirmaier
Copy link
Member Author

I've worked in the feedback, thank you @kevinrushforth
Small note, this change is not used for a while and is therefore well tested.

@kevinrushforth kevinrushforth self-requested a review July 22, 2022 16:00
Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look fine now. Since this PR is so out of date w.r.t. master, can you merge the upstream master into your PR branch? I'll do some quick testing and then approve it, once you do.

You will also need to update the title of this PR to match the JBS issue (the JBS bug title is the better one), before it can be integrated.

latch.countDown();
});
latch.await();
} catch (Throwable e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure whether we need to catch Throwable here, but we use that pattern all over the place in this file, so it can be reexamined as part of the cleanup bug I will file.

@kevinrushforth
Copy link
Member

@FlorianKirmaier This PR is pending the following:

  1. Merge upstream master into your PR branch (so we can get a clean test run on the latest + your changes)
  2. Change this PR title to 8271395: Crash during printing when disposing textures

@FlorianKirmaier FlorianKirmaier changed the title 8271395: Fixing crash at printing 8271395: Crash during printing when disposing textures Aug 19, 2022
@FlorianKirmaier
Copy link
Member Author

@kevinrushforth
I've just seen your comments.
I've just merged it and changed the title!

@FlorianKirmaier
Copy link
Member Author

The Mac build seems to be failing for some reason, unrelated to the PR.

@kevinrushforth
Copy link
Member

Yes, that is due to JDK-8292549 which is fixed by the soon-to-be-integrated PR #879

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@openjdk
Copy link

openjdk bot commented Aug 19, 2022

@FlorianKirmaier This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8271395: Crash during printing when disposing textures

Reviewed-by: kcr, prr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 1 new commit pushed to the master branch:

  • cedc17c: 8292549: GitHub actions: intermittent build failure on macOS while downloading ant

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@kevinrushforth, @prrace) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Ready to be integrated label Aug 19, 2022
@FlorianKirmaier
Copy link
Member Author

/integrate

@openjdk openjdk bot added the sponsor Ready to sponsor label Aug 20, 2022
@openjdk
Copy link

openjdk bot commented Aug 20, 2022

@FlorianKirmaier
Your change (at version 27bf883) is now ready to be sponsored by a Committer.

@kevinrushforth
Copy link
Member

/sponsor

@openjdk
Copy link

openjdk bot commented Aug 20, 2022

Going to push as commit 8815981.
Since your change was applied there has been 1 commit pushed to the master branch:

  • cedc17c: 8292549: GitHub actions: intermittent build failure on macOS while downloading ant

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Aug 20, 2022
@openjdk openjdk bot closed this Aug 20, 2022
@openjdk openjdk bot removed ready Ready to be integrated rfr Ready for review sponsor Ready to sponsor labels Aug 20, 2022
@openjdk
Copy link

openjdk bot commented Aug 20, 2022

@kevinrushforth @FlorianKirmaier Pushed as commit 8815981.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

4 participants