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

8276058: Some swing test fails on specific CI macos system #6140

Closed
wants to merge 6 commits into from

Conversation

prsadhuk
Copy link
Contributor

@prsadhuk prsadhuk commented Oct 27, 2021

As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
It was seen from the logs that we have color mismatch in these tests.

For example, in PressedIcon test, we had following log

----------System.out:(1/75)----------
color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
----------System.err:(13/842)----------
java.lang.RuntimeException: Colors is different for scale=1!
at PressedIconTest.main(PressedIconTest.java:97)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
at java.base/java.lang.reflect.Method.invoke(Method.java:569)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)

and JInternalFrame test, we had
----------System.err:(15/939)----------
FRAME_COLOR Red: 255; Green: 200; Blue: 0
Pixel color Red: 55; Green: 55; Blue: 55
java.lang.RuntimeException: Internal frame is not correctly dragged!
at bug8069348.main(bug8069348.java:96)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
at java.base/java.lang.reflect.Method.invoke(Method.java:569)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)

where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.

The awt tests that are failing seems to have different root cause and will be handled separately.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8276058: Some swing test fails on specific CI macos system

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6140/head:pull/6140
$ git checkout pull/6140

Update a local copy of the PR:
$ git checkout pull/6140
$ git pull https://git.openjdk.java.net/jdk pull/6140/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6140

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6140.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Oct 27, 2021

👋 Welcome back psadhukhan! 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
Copy link

@openjdk openjdk bot commented Oct 27, 2021

@prsadhuk The following label will be automatically applied to this pull request:

  • client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the client label Oct 27, 2021
@openjdk openjdk bot added the rfr label Oct 27, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Oct 27, 2021

Webrevs

robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
robot.waitForIdle();
Color color = robot.getPixelColor(centerX-10, centerY-10);

Copy link
Contributor

@prrace prrace Oct 27, 2021

Choose a reason for hiding this comment

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

So the problematic pattern is a mouse move to the location from which you subsequently capture a pixel?
I can see how on a compositing window manager that might be an issue as the cursor is part of the window
whereas on old X11 it isn't part of the root window .. but why isn't this ALWAYS an issue on macOS ?

I wonder how many other tests have the same issue ?

And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation ..

Copy link
Member

@azvegint azvegint Oct 27, 2021

Choose a reason for hiding this comment

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

Robot doesn't capture a cursor, we have a Robot#createScreenCapture spec which clearly says that:

Creates an image containing pixels read from the screen.
This image does not include the mouse cursor.

Both Robot#createScreenCapture and Robot#getPixelColor are using the same CRobot#nativeGetScreenPixels method for getting pixel data.

So the mouse cursor should not affect `Robot#getPixelColor`, this is easy to check on practice
import javax.imageio.ImageIO;
import java.awt.AWTException;
import java.awt.Color;
import java.awt.Frame;
import java.awt.Rectangle;
import java.awt.Robot;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;

public class CursorTest {
    public static void main(String[] args) throws AWTException, IOException {
        Robot robot = new Robot();

        Frame frame = new Frame();
        frame.setBackground(Color.red);
        frame.setUndecorated(true);

        Rectangle rectangle = new Rectangle(100,100,50,50);
        frame.setBounds(rectangle);
        frame.setVisible(true);

        robot.waitForIdle();
        robot.delay(1000);
        robot.mouseMove(rectangle.x + 5, rectangle.y + 5);
        robot.waitForIdle();

        System.err.println("Moved");
        robot.waitForIdle();
        robot.delay(3000);

        System.err.println("Starting");

        BufferedImage screenCapture = robot.createScreenCapture(rectangle);
        ImageIO.write(screenCapture, "png", new File("/tmp/out.png"));

        for (int i = rectangle.x; i < rectangle.x + rectangle.width; i++) {
            for (int j = rectangle.y; j < rectangle.y + rectangle.height; j++) {
                Color pixelColor = robot.getPixelColor(i, j);
                if (!pixelColor.equals(Color.red)) {
                    System.err.println(pixelColor);
                    frame.dispose();
                    throw new RuntimeException("Unexpected pixel color " + pixelColor);
                }
            }
        }

        System.err.println("Finished");
        frame.dispose();
    }
}

Copy link
Contributor

@prrace prrace Oct 27, 2021

Choose a reason for hiding this comment

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

Ok .. yet Prasanta said it did ..
"The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to."

Rectangle screen = new Rectangle(0, 0, (int) screenSize.getWidth(), (int) screenSize.getHeight());
BufferedImage img = robot.createScreenCapture(screen);
javax.imageio.ImageIO.write(img, "png", new java.io.File("image.png"));

Copy link
Contributor

@prrace prrace Oct 27, 2021

Choose a reason for hiding this comment

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

Are we writing the image or any other type of file in the CWD in other tests ?
Shouldn't this use TESTCLASSES or something like that ?

}
System.out.println("Test Passed");
Copy link
Contributor

@prrace prrace Oct 27, 2021

Choose a reason for hiding this comment

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

Hmm .. the test tags are

  • @run main/othervm PressedIconTest
  • @run main/othervm -Dsun.java2d.uiScale=2 PressedIconTest

What if the default scale is 2 ?
Or on Windows it could be 1.25 ?
I don't see anything that restricts this test to macOS.

If you are going to explicitly test for 1 and 2 here, shouldn't we explicitly set it ?

And if you aren't then the test here needs to do something based on the actual scale.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

Since it is unlikely to be the issue related to the cursor, it will be better to check what could be root cause. Is it possible that CI system is configured in some different way as others? Th 55/55/55 color looks similar to the background of the app in the dark mode in macOS, could it be the reason?

@prrace
Copy link
Contributor

@prrace prrace commented Oct 28, 2021

Since it is unlikely to be the issue related to the cursor,
it will be better to check what could be root cause.

Well .. the cursor issue is a suggestion for root cause [*] Do you have any other ideas ? I mean other than ...

Is it possible that CI system is configured in some different way as others?

Not that I can see and definitely not dark mode. Permanent light mode.

@openjdk openjdk bot removed the rfr label Oct 28, 2021
@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Oct 28, 2021

awt test fix also added

FullScreenInsets fails with incorrect pixel so added tolerance
----------System.err:(15/899)----------
Incorrect pixel at 298x246 : ff00fe00 ,expected : ff00ff00
Incorrect pixel at 298x246 : fffe0000 ,expected : ffff0000
java.lang.RuntimeException: Test failed
at FullScreenInsets.main(FullScreenInsets.java:93)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
at java.base/java.lang.reflect.Method.invoke(Method.java:569)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)

MakeWindowAlwaysOnTop fails with same root cause so used same swing tactics of x-10, y-10
----------System.out:(1/39)----------
Color = java.awt.Color[r=55,g=55,b=55]
----------System.err:(13/909)----------
java.lang.RuntimeException: Test FAILED: unknown window is on top of the frame
at MakeWindowAlwaysOnTop.main(MakeWindowAlwaysOnTop.java:120)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
at java.base/java.lang.reflect.Method.invoke(Method.java:569)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)

@openjdk openjdk bot added the rfr label Oct 28, 2021
@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

Well .. the cursor issue is a suggestion for root cause [*] Do you have any other ideas ? I mean other than ...

As noted above our spec mention that the cursor should not be present on the screenshot, and we use the appropriate native API to achieve this. It is hard to say why it does not work, but since the problem is consistent which is great, then the best way to investigate it is by connecting to the system and debugging the problem.

  • Since in some cases the getPixelColor() method is used it could be related to the #5864, where I have proved that this method may return the garbage instead of correct data. Without that fix the usage of that method is UB. But as mentioned in some other JBS, it may not be enough, probably some other bugs exist.
  • Maybe it is a timing issue like this #5373 but in OGL this time and we draw a garbage for a moment when we did a screenshot.
  • it could also be related to the video card, so on some systems, we use one code path and the other on another system. By using metal we can prove that the bug is in the robot. And by using the native app we can prove is a bug in the robot implementation or not.
  • It also could be related to the system DPI/screen resolution, how it will work if the test will run using scale=1?

The awt tests that are failing seems to have different root cause and will be handled separately.

In general, it does not look like a test issue, more like a product bug. So the root cause of this particular issue should be investigated.

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Oct 28, 2021

I have attached 2 screen capture in JBS taken when PressedIconTest and JInternalFrame test failed and the screenshot at least in this machine shows presence of cursor.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

I have attached 2 screen capture in JBS taken when PressedIconTest and JInternalFrame test failed and the screenshot at least in this machine shows presence of cursor.

So maybe something was changed in the native API? It looks like a tck issue that breaks the specified behavior. Is it happen only on this system? Could it be related to the cursor configuration in the settings, size/visibility/scale etc?

@prrace
Copy link
Contributor

@prrace prrace commented Oct 28, 2021

I have attached 2 screen capture in JBS taken when PressedIconTest and JInternalFrame test failed and the screenshot at least in this machine shows presence of cursor.

So maybe something was changed in the native API? It looks like a tck issue that breaks the specified behavior. Is it happen only on this system? Could it be related to the cursor configuration in the settings, size/visibility/scale etc?

See the comment I just added to https://bugs.openjdk.java.net/browse/JDK-8252813.

It still needs verification to see if it affects the macOS API used. But it seems probable something like that is going on.
Regardless I think we may need to revise the Robot spec a little ... I don't know why it is so insistent that the cursor is NOT captured since it seems something outside control of the Robot ..

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

Yes looks like it is related to the cursor size in the settings
Settings->Accessibility->Display->Cursor tab->Increase the size of the cursor to large.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

I think we should report this to Apple.

@prrace
Copy link
Contributor

@prrace prrace commented Oct 28, 2021

Yes looks like it is related to the cursor size in the settings
Settings->Accessibility->Display->Cursor tab->Increase the size of the cursor to large.

Sorry, not following .. do you mean you think the cursor is captured when it is enlarged ?
Like somehow a software cursor is used that is painted in a different way so that it always show up ?
But the screen captures in the bug report seem to show a small cursor and the above A11Y setting on the
test system has Cursor Size: Normal (ie the very minimum of the slider)

BTW when accessing the test system remotely it seems that A11Y feature is disabled. The slider has no effect.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

Sorry, not following .. do you mean you think the cursor is captured when it is enlarged ? Like somehow a software cursor is used that is painted in a different way so that it always show up ? But the screen captures in the bug report seem to show a small cursor and the above A11Y setting on the test system has Cursor Size: Normal (ie the very minimum of the slider)

I can confirm that the changing the size of the cursor on that setting page can change the visibility of the cursor on the screenshot. If the cursor is "small" then it is completely invisible, if the cursor size is changed above some threshold it became visible on the screenshot. So it might be a case when on that system the default cursor is bigger that the threshold.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

BTW when accessing the test system remotely it seems that A11Y feature is disabled. The slider has no effect.

So probably the local settings is not default/changed, and what is shown on the setting you see is for remote view?

@prrace
Copy link
Contributor

@prrace prrace commented Oct 28, 2021

Sorry, not following .. do you mean you think the cursor is captured when it is enlarged ? Like somehow a software cursor is used that is painted in a different way so that it always show up ? But the screen captures in the bug report seem to show a small cursor and the above A11Y setting on the test system has Cursor Size: Normal (ie the very minimum of the slider)

I can confirm that the changing the size of the cursor on that setting page can change the visibility of the cursor on the screenshot. If the cursor is "small" then it is completely invisible, if the cursor size is changed above some threshold it became visible on the screenshot. So it might be a case when on that system the default cursor is bigger that the threshold.

Hmm .. well it is at the minimum right now. So throw that one in the bag of things that can go wrong .. but I'm not currently seeing it set to anything except absolute minimum,
But we could change it manually and see if that toggles whether the unmodified tests pass or fail ..

The mechanism by which any of these things suddenly happen and then suddenly go away is really unclear to me ..
but at least it makes sense that these can persist across reboots

@prrace
Copy link
Contributor

@prrace prrace commented Oct 28, 2021

BTW when accessing the test system remotely it seems that A11Y feature is disabled. The slider has no effect.

So probably the local settings is not default/changed, and what is shown on the setting you see is for remote view?

Well I can move the slider so I think I am seeing the REAL setting but it just doesn't get used in screen sharing mode

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

I tried it on the other macOS system, this time aarch64. And the cursor is visible there even if the size is set to small.
So it will be good to report this to Apple, looks like a regression.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 28, 2021

Looks like sometimes the cursor may be rendered in the framebuffer and sometimes not:
https://developer.apple.com/documentation/coregraphics/1541804-cgcursorisdrawninframebuffer?language=objc

(The cursor could exist in an overlay plane or a similar mechanism that puts pixels on-screen without altering framebuffer content.) If the cursor is drawn in the framebuffer, it is read back along with window data.

Maybe we should wrap the taking screenshot by the CGDisplayHideCursor/CGDisplayShowCursor.

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Oct 29, 2021

    Shouldn't this use TESTCLASSES or something like that ?

We have used the same way of ImageIO.write() in jtreg tests

OK ..doesn't mean its right please check with jtreg devs etc ..

If it's not right, then we have to change at so many files..All files uses the same approach so I followed...Where to ask? not sure about jtreg devs contact?

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 29, 2021

I pointed that out earlier .. even before you raised the cursor size issue.

Missed that, and still cannot find it by searching the discussion above, I probably need to rest

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Oct 29, 2021

I pointed that out earlier .. even before you raised the cursor size issue.

Missed that, and still cannot find it by searching the discussion above, I probably need to rest

It was added as part of https://bugs.openjdk.java.net/browse/JDK-8252813 comment mentionedin this PR.

@mrserb
Copy link
Member

@mrserb mrserb commented Oct 29, 2021

It was added as part of https://bugs.openjdk.java.net/browse/JDK-8252813 comment mentionedin this PR.

So it is even a different bug =(..
Looks like that comment was about using some shortcuts and options, I was talking about using "screencapture" tool in the command line and just passing or skipping the -C option, so it is easy to check how the cursor behaves during screen capture.
So I think the best next step is to report it to Apple as I suggested and get some feedback.

@prrace
Copy link
Contributor

@prrace prrace commented Oct 29, 2021

I pointed that out earlier .. even before you raised the cursor size issue.

Missed that, and still cannot find it by searching the discussion above, I probably need to rest

I had written (above many hours ago) -

See the comment I just added to https://bugs.openjdk.java.net/browse/JDK-8252813.

It still needs verification to see if it affects the macOS API used. But it seems probable something like that is going on.
Regardless I think we may need to revise the Robot spec a little ... I don't know why it is so insistent that the cursor is NOT captured since it seems something outside control of the Robot ..

@prrace
Copy link
Contributor

@prrace prrace commented Oct 29, 2021

It was added as part of https://bugs.openjdk.java.net/browse/JDK-8252813 comment mentionedin this PR.

So it is even a different bug =(.. Looks like that comment was about using some shortcuts and options, I was talking about using "screencapture" tool in the command line and just passing or skipping the -C option, so it is easy to check how the cursor behaves during screen capture. So I think the best next step is to report it to Apple as I suggested and get some feedback.

  • No it is the same thing - the shorcut was just the mechanism to pull up the settings dialog.

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Nov 8, 2021

I have removed the tolerance change and PL-ed the test....Any more comments on this PR?

@mrserb
Copy link
Member

@mrserb mrserb commented Nov 9, 2021

I have removed the tolerance change and PL-ed the test....Any more comments on this PR?

If tolerance is not needed and the only issue we have is the visible cursor on the screenshot then why do we try to update the tests, maybe we can try to update the jdk instead?

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Nov 10, 2021

If tolerance is not needed and the only issue we have is the visible cursor on the screenshot then why do we try to update the tests, maybe we can try to update the jdk instead?

I guess it was already discussed before as below to have the stability improvement in the tests and you agreed to it also but if the stance is changed, I do not have issue in withdrawing this PR.

The test part of the fix has multiple stability improvements, and there's no reason to throw that out. And moving the pixel capture position to a more safe position is fine too. I just think that -10 isn't sa\fe enough.

Sure, I have no comments about the changes related to stability, but there are suspicious cases like using tolerance.

@prrace
Copy link
Contributor

@prrace prrace commented Nov 10, 2021

I don't see a reason to discard the various stability improvements.
The discussion is long so I may not be summarising correctly but

  • A product fix may resolve most of the issues and yet
  • Stability fixes are still valuable
  • The one test with a colour tolerance update may be better platform problem listed
  • The offset of -10,-10 for the cursor maybe better if it was parameterised and a bit bigger.

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Nov 10, 2021

I guess the last 2 is already taken care of in latest iteration.

@mrserb
Copy link
Member

@mrserb mrserb commented Nov 14, 2021

It is a good thing to stabilize the tests and provide additional logging/screenshots at the end, but isn't taking the screenshot out of the mouse is a workaround for the bug?

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Nov 15, 2021

It probably is but will not affect the regression testing of these tests for its specific JBS issues it was written for. Also, the CI system will have to be kept offline till a product fix is found and tested so I think it is prudent to apply this patch to make this CI system usable again...

@mrserb
Copy link
Member

@mrserb mrserb commented Nov 17, 2021

ok, it is up to you.

@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Nov 17, 2021

@prrace Do you have any comments? If not, can you please approve?

prrace
prrace approved these changes Nov 17, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 17, 2021

@prsadhuk 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:

8276058: Some swing test fails on specific CI macos system

Reviewed-by: prr, kizune

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 360 new commits pushed to the master branch:

  • b687664: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points
  • 8f5a8f7: 8264293: Create implementation for NSAccessibilityMenu protocol peer
  • 9f2f46e: 8275037: Test vmTestbase/nsk/sysdict/vm/stress/btree/btree011/btree011.java crashes with memory exhaustion on Windows
  • 2af9e59: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test
  • e9934e1: 8277221: G1: Remove methods without implementations in G1CollectedHeap
  • 9aa30de: 8275317: AArch64: Support some type conversion vectorization in SLP
  • 08f65a5: 8277313: Validate header failed for test/jdk/java/net/httpclient/HeadTest.java
  • 23e5117: 8276559: (httpclient) Consider adding an HttpRequest.Builder.HEAD method to build a HEAD request.
  • a77d8dd: 8276787: Improve warning messages for -XX:+RecordDynamicDumpInfo
  • 8ed384c: 8276609: Document setting property jdk.serialFilter to an invalid value throws ExceptionInInitializerError
  • ... and 350 more: https://git.openjdk.java.net/jdk/compare/bd0bed71e55f0bb8b4619495c79184f94c0701fb...master

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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Nov 17, 2021
@prsadhuk
Copy link
Contributor Author

@prsadhuk prsadhuk commented Nov 18, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Nov 18, 2021

Going to push as commit 9160743.
Since your change was applied there have been 372 commits pushed to the master branch:

  • 8193800: 8274179: AArch64: Support SVE operations with encodable immediates
  • b8453eb: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales
  • 231fb61: 8276970: Default charset for PrintWriter that wraps PrintStream
  • 29e552c: 8272358: Some tests may fail when executed with other locales than the US
  • ce4471f: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64
  • 45a60db: 8277045: G1: Remove unnecessary set_concurrency call in G1ConcurrentMark::weak_refs_work
  • 6bb0462: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
  • d8c0280: 8277316: ciReplay: dump_replay_data is not thread-safe
  • 007ad7c: 8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs
  • 8881f29: 8277310: ciReplay: @CPI MethodHandle references not resolved
  • ... and 362 more: https://git.openjdk.java.net/jdk/compare/bd0bed71e55f0bb8b4619495c79184f94c0701fb...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Nov 18, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Nov 18, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 18, 2021

@prsadhuk Pushed as commit 9160743.

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

@prsadhuk prsadhuk deleted the JDK-8276058 branch Nov 18, 2021
@mrserb
Copy link
Member

@mrserb mrserb commented Mar 7, 2022

@prsadhuk @prrace Did we report this to Apple? I have found that some of the tck tests could be unstable due to this, and "CGDisplayHideCursor/CGDisplayShowCursor" may cure it, but probably Apple suggests something else?

@prrace
Copy link
Contributor

@prrace prrace commented Mar 7, 2022

I can't see that we did but I have now.
One thing that occurred to me is that
Settings->Accessibility->Display->Shake mouse pointer to locate
is enabled by default and if our tests "warping" the pointer trigger this then maybe it could be why we see the pointer - I can imagine that the mode for large pointer isn't immediately turned off.
So disabling that setting maybe is worth adding to all our systems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client integrated
5 participants