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

8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" #4036

Closed
wants to merge 4 commits into from

Conversation

alitvinv
Copy link
Member

@alitvinv alitvinv commented May 14, 2021

Hello,

Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print​(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.

ROOT CAUSE OF THE BUG:
The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression

"int pageResult = printable.print(graphics, pageFormat, pageIndex);"

is caught but is not returned to a developer by any mean or is not printed out to the error stream.

THE FIX:
The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:

  • on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
  • on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.

The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.

Thank you,
Anton


Progress

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

Issue

  • JDK-8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4036

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

Using diff file

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

@bridgekeeper
Copy link

bridgekeeper bot commented May 14, 2021

👋 Welcome back alitvinov! 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 label May 14, 2021
@openjdk
Copy link

openjdk bot commented May 14, 2021

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

  • awt

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 awt label May 14, 2021
@mlbridge
Copy link

mlbridge bot commented May 14, 2021

Webrevs

@alitvinv
Copy link
Member Author

alitvinv commented May 14, 2021

/label add 2d

@openjdk openjdk bot added the 2d label May 14, 2021
@openjdk
Copy link

openjdk bot commented May 14, 2021

@alitvinv
The 2d label was successfully added.

@alitvinv
Copy link
Member Author

alitvinv commented May 14, 2021

/label remove awt

@openjdk openjdk bot removed the awt label May 14, 2021
@openjdk
Copy link

openjdk bot commented May 14, 2021

@alitvinv
The awt label was successfully removed.

@alitvinv
Copy link
Member Author

alitvinv commented May 17, 2021

/label add awt

@openjdk openjdk bot added the awt label May 17, 2021
@openjdk
Copy link

openjdk bot commented May 17, 2021

@alitvinv
The awt label was successfully added.

@alitvinv
Copy link
Member Author

alitvinv commented May 17, 2021

Publishing this RFR on the e-mail alias (2d-dev@openjdk.java.net) by writing this comment. Dear reviewers from (2d-dev@openjdk.java.net) e-mail alias, could you please review this RFR.

Copy link
Contributor

@prrace prrace left a comment

I'm a bit surprised the test passes on windows.
Perhaps because you aren't trying RuntimeException ?

throw new PrinterException("Exception from Printable.print");
}
});
if (job.printDialog()) {
Copy link
Contributor

@prrace prrace May 19, 2021

Choose a reason for hiding this comment

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

why do we need a dialog ? If you remove this it can be an automated test.

Copy link
Member Author

@alitvinv alitvinv May 21, 2021

Choose a reason for hiding this comment

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

Hello Phil. Thank you very much for review of this fix. First I am answering your question, which is about why the test passes on Windows and which is your first and separate comment not bound to the source code. The test passes on Windows, because in JDK 17 for both Windows and Linux JDK works similarly stably and reliably, JDK 17 on Window and Linux successfully propagates "PrinterException" and "RuntimeException", if it is thrown from "Printable.print" method. I had verified this using my standalone manual test case "ExceptionFromPrintableIsIgnored.java" attached to the bug record in JBS, before sending the 1st version of the fix for review. I did not explore, why it is so, because it works on Windows and Linux and this bug is related to macOS, but I think that it works on Windows and Linux, because in JDK implementations for Windows and Linux printing is consistently done by JDK on the same thread on which "PrinterJob.print" was called and no portions of the involved code are executed asynchronously on other thread, like EDT in case of macOS.

I agree there is no need in the dialog in the regression test. In the 1st version of the fix I did it deliberately, to make it more manual, because the test initiates printing and there is no guarantee what type of printer would be set up on the test host, if some virtual printer is used on the host, that printer can show its own native dialog asking to specify location of a file, in which the printed document should be saved. That is why I think that this test cannot be fully automatic. In the 2nd version of the fix which I am submitting right now I removed this unnecessary code showing JDK print dialog.

@summary Verify that "PrinterJob.print" throws the exception, if
"Printable.print" throws "PrinterException".
@run main/manual ExceptionFromPrintableIsIgnoredTest MAIN
@run main/manual ExceptionFromPrintableIsIgnoredTest EDT
Copy link
Contributor

@prrace prrace May 19, 2021

Choose a reason for hiding this comment

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

See comment below

if (pageIndex > 1) {
return NO_SUCH_PAGE;
}
throw new PrinterException("Exception from Printable.print");
Copy link
Contributor

@prrace prrace May 19, 2021

Choose a reason for hiding this comment

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

Don't you want to also test this with some kind of RuntimeException ?

Copy link
Member Author

@alitvinv alitvinv May 21, 2021

Choose a reason for hiding this comment

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

In the 1st version of the fix I did not test the scenario with "RuntimeException", because despite of the fact that I had known that JDK 17 will pass on Windows and Linux the scenario with "RuntimeException" I still was not sure if the behavior of older JDK release families is the same with JDK 17 on Windows and Linux, and just did not want to run the risk of failure of this test during potential porting of the fix to older JDK release families.

But yesterday I did testing with my standalone test case attached to the bug record in JBS and now I can certainly say that JDK 8u291-b10, JDK JDK 8-b132 do not fail in the test scenarios with "RuntimeException" on Windows and Linux. Therefore it is safe to include test scenario with "RuntimeException" to the regression test.

In the 2nd version of the fix now I am testing also "RuntimeException" both on EDT thread and on main thread.

if (lastPrintEx instanceof PrinterException) {
throw (PrinterException) lastPrintEx;
} else if (lastPrintEx instanceof RuntimeException) {
throw (RuntimeException) lastPrintEx;
Copy link
Contributor

@prrace prrace May 19, 2021

Choose a reason for hiding this comment

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

I don't see you testing this case
And do I understand correctly that this only throws the exception at the end of the printloop after trying all pages ?

Copy link
Member Author

@alitvinv alitvinv May 21, 2021

Choose a reason for hiding this comment

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

In the 2nd version of the fix I added testing of the scenario with "RuntimeException".

Yes, this code is executed only after the execution of the "printLoop" is fully finished for each of all page ranges. If printing of one page fails within one page range, then printing of other pages does not occur. "CPrinterJob.print(PrintRequestAttributeSet)" is blocking until printing is finished or fails, and my code is executed in the very end of the method.

private Exception setLastPrintEx(Exception newEx, boolean printOldEx) {
Exception oldEx = lastPrintExRef.getAndSet(newEx);
if (printOldEx && (oldEx != null)) {
oldEx.printStackTrace();
Copy link
Contributor

@prrace prrace May 19, 2021

Choose a reason for hiding this comment

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

Why not Throwable ?
I suggest to not do this. ie don't print and don't replace Instead swallow the new exception
and let the original problem that started it get propagated. That seems more likely to be useful.

Copy link
Member Author

@alitvinv alitvinv May 21, 2021

Choose a reason for hiding this comment

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

Thank you for this remark. I agree using "Throwable" is more solid approach. In the 2nd version of the fix I use "Throwable" in this "AtomicReference" object and I removed completely this method "setLastPrintEx".

ret[0] = getPageFormatArea(pageFormat);
}
} catch (Exception e) {
// Original code bailed on any exception
Copy link
Contributor

@prrace prrace May 19, 2021

Choose a reason for hiding this comment

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

Throwable ?
And what was wrong with bailing ? That comment has been there since the code was brought into OPenJDK so I can't tell what the motivation was.
But I'm getting a bit lost what is going on here.

The spec https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/print/Printable.html#print(java.awt.Graphics,java.awt.print.PageFormat,int)

says
Throws:
PrinterException - thrown when the print job is terminated.

I take that to mean we should not carry on printing .. but it looks like we just note the exception and carry on.
I'm not sure this code (pre-existing behaviour) is right.

We do want to grab the exception so it doesn't mess up interverning code but don't we want this to reach the caller of PrinterJob.print - in the form of a PrinterExcepton ?

Copy link
Member Author

@alitvinv alitvinv May 21, 2021

Choose a reason for hiding this comment

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

In the 2nd version of the fix I substituted "Exception" for "Throwable" in this catch block and in second "catch" block several lines below. Also in the 2nd fix version I removed this comment about bailing.

My opinion is the same, the code before the fix did not work according to the specification and was ignoring any caught exceptions. Perhaps, the reason of this is involvement of more than 1 thread in the code flow standing behind "PrinterJob.print" method execution and execution of the JDK's code through JNI in this code flow. Thus propagating the exception is impossible across threads and it is not easy to stop printing done by macOS at the moment, when the exception occurs in Java code in JDK. This pattern is used in the file "CPrinterJob.java" in other places, even there is the same comment in the method "CPrinterJob.getPageformatPrintablePeekgraphics". At the same time propagating "RuntimeException" from "PrinterJob.print" on Windows, Linux and now on macOS after this fix also is not according to the specification but still consistency in JDK behavior on these OS versions should be good.

As I understand, the method "CPrinterJob.printAndGetPageFormatArea" returns "null" as the "Rectangle2D", when the exception is caught, and this "null" value should automatically lead to returning of "NSZeroRect" from the Objective-C method "(NSRect)rectForPage:(NSInteger)pageNumber" in the file "src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m", from which "CPrinterJob.printAndGetPageFormatArea" Java method was invoked. And this "NSZeroRect" return value is indication of the error for macOS, which further leads to stopping of the printing process.

@alitvinv
Copy link
Member Author

alitvinv commented May 21, 2021

Hello Phil,

I have uploaded the 2nd version of the fix, which addresses your remarks. Could you please review it, also I provided answers to all your comments. Changes in the 2nd version of the fix are following:

  1. The created atomic reference object now stores "Throwable" instance instead of "Exception", the variable itself is renamed to "printErrorRef".
  2. The method "setLastPrintEx" introduced by the 1st version of the fix is completely removed.
  3. "catch" blocks in the method "CPrinterJob.printAndGetPageFormatArea" now catches "Throwable" instead of "Exception".
  4. The regression test now tests also "RuntimeException" on EDT and on the main thread.
  5. The regression test now does not show any JDK print dialog.

Thank you,
Anton

@run main/manual ExceptionFromPrintableIsIgnoredTest MAIN PE
@run main/manual ExceptionFromPrintableIsIgnoredTest MAIN RE
@run main/manual ExceptionFromPrintableIsIgnoredTest EDT PE
@run main/manual ExceptionFromPrintableIsIgnoredTest EDT RE
Copy link
Contributor

@prrace prrace May 30, 2021

Choose a reason for hiding this comment

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

wjy is this still manual ?

Copy link
Member Author

@alitvinv alitvinv May 31, 2021

Choose a reason for hiding this comment

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

The test is manual, because the test initiates printing and there is a chance that on a test host a default printer will be some virtual printer which can show the native dialog asking to specify the location of PDF file in which the printed document should be saved, in this case the test will be blocked and will be killed by "jtreg" by a timeout, what is unacceptable for the automatic test which should not slow down the speed of execution of all other automatic tests. For example such a virtual printer on Windows OS can be "Microsoft Print to PDF". By the way, I already explained this reason in one of my replies to your questions in the previous iteration of the code review.

Copy link
Contributor

@prrace prrace Jun 8, 2021

Choose a reason for hiding this comment

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

I thought I also explained that the printer keyword means it would only be run if the system has a real printer by virtue of it being set in the jtreg run. You could also do that on a virtual printer if you didn't mind entering the file name

private void runTest(final TestExceptionType exceptionType) {
PrinterJob job = PrinterJob.getPrinterJob();
if (job.getPrintService() == null) {
throw new RuntimeException("No printers are available.");
Copy link
Contributor

@prrace prrace May 30, 2021

Choose a reason for hiding this comment

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

where does this exception go if it happens and you are on EDT ?

Copy link
Member Author

@alitvinv alitvinv May 31, 2021

Choose a reason for hiding this comment

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

If this exception happens on EDT, this exception as any other exception thrown from the method "runTest" will be perfectly caught and handled in "catch" block of the constructor of the test "ExceptionFromPrintableIsIgnoredTest" as "InvocationTargetException" instance, which will have this "RuntimeException" as its cause. The whole test relies on this approach of throwing and catching the exception and it works.

return;// Test passed.
}
throw new RuntimeException("Unexpected exception was thrown.");
} else {
Copy link
Contributor

@prrace prrace May 30, 2021

Choose a reason for hiding this comment

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

When running on the EDT do you really want to do this ?

Copy link
Member Author

@alitvinv alitvinv May 31, 2021

Choose a reason for hiding this comment

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

Yes, I do really want to do this, when running on EDT, the whole test relies on this approach. When the test is run on EDT this is done via "SwingUtilities.invokeAndWait" method in the constructor of the test "ExceptionFromPrintableIsIgnoredTest" and in that constructor there is "try/catch" block. If some exception occurs on EDT and is not caught on EDT, then it will be wrapped by JDK in "InvocationTargetException" instance which will be thrown from "SwingUtilities.invokeAndWait" method and will be caught by that "try/catch" block in the constructor of the test. I checked that this code works before sending the code for review and today additionally.

if (((printEx instanceof PrinterException) &&
(exceptionType == TestExceptionType.PE)) ||
((printEx instanceof RuntimeException) &&
(exceptionType == TestExceptionType.RE))) {
Copy link
Contributor

@prrace prrace May 30, 2021

Choose a reason for hiding this comment

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

  1. I am fairly sure that I tested this case on Windows and nothing caught it so does this test work on Windows ?

  2. I raised the question / suggestion that should we not wrap these in a PrinterException ?
    It at least needs to be thought through.

Copy link
Member Author

@alitvinv alitvinv May 31, 2021

Choose a reason for hiding this comment

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

  1. The test does not fail on Windows in all 4 tested scenarios. You can run this regression test on Windows and you will see in the test report in the test output that the test successfully throws the required "PrinterException" or "RuntimeException" from "java.awt.print.Printable.print​(Graphics, PageFormat, int)" and that the test successfully catches this "PrinterException" or "RuntimeException" and prints out it to "System.out" "PrintStream" in the test method "ExceptionFromPrintableIsIgnoredTest.runTest(final TestExceptionType)".

Line 115 printEx.printStackTrace(System.out);

This line in the test is done exactly as the evidence that the exception was really propagated from the method "PrinterJob.print()" and caught by the test. I verified that it is "true" on macOS, Windows, Linux.

I reported this in the code review and in JBS bug record itself that in JDK 17 and in JDK 8u291 and even in JDK 8-b132 on Windows and on Linux "PrinterJob.print()", which is called on EDT, propagates "PrinterException" and "RuntimeException" which are thrown from "Printable.print​(Graphics, PageFormat, int)" method. If you still do not trust this, then I suggest you just to recheck it yourself by any trustworthy mean in addition to this regression test and the purely manual test case "ExceptionFromPrintableIsIgnored.java" attached to the bug record.

  1. By current moment in JDK versions on Windows and Linux the "RuntimeException" thrown from "Printable.print​(Graphics, PageFormat, int)" has been propagated through "PrinterJob.print()" as is without wrapping it into "PrinterException", as my experiments show even in JDK 8-b132 and in currently latest GA release of JDK 8 and in JDK 17.

From my viewpoint not wrapping "RuntimeException" into "PrinterException" and propagating "RuntimeException" through "PrinterJob.print()" will just bring behavior of JDK on macOS into correspondence with existing behavior of JDK on Windows and Linux. If we wrap "RuntimeException" into "PrinterException" on macOS, then at some point in time somebody will need to change JDK code for Windows and Linux to also do the same wrapping of the exception which is currently not done. I do not insist on any variant.

Copy link
Contributor

@prrace prrace left a comment

The points I have been trying to make are that

  1. We need to make sure that important cleanup happens rather than just bailing
  2. Despite Windows + Linux propagating a RTE, I am not sure this is what we want.
    If the RTE is something the app decides to throw, then that's one thing but
    if something went wrong in the bowels of printing the spec says it should be a PrinterException.
    At the very least we should make sure temp files are deleted, any open calls
    to startDoc have been matched with a close ..

Hence my early comment "The exception should not propagate. State may need to be cleaned up.
If you do anything you would make it the init cause of the PrinterException."
That means if we see an RTE propagated .. that could be a bug.

So I am nor comfortable just "aligning" the behaviour with WIndows and Linux without being
sure they are correct.

In other words, mac was probably catching this to do the clean up part, and that was likely OK
But yes, it probably was wrong not to rethrow as a wrapped (if needed) PrinterException

But although it opens a whole new can of worms I was suggesting you needed to look closely
at windows + linux and not just create a test which verified behaviour I am not sure we want.

I questioned the test etc about RTE because although it is good to test hrowing RTE you
are verifying it ARRIVES still as an RTE, and I think it should be a PrinterException.

I am open to discussion about why this may be "actually OK" but it has to be better than
"the others are doing it" and it definitely should not be a reason to leave open files/jobs.

@run main/manual ExceptionFromPrintableIsIgnoredTest MAIN PE
@run main/manual ExceptionFromPrintableIsIgnoredTest MAIN RE
@run main/manual ExceptionFromPrintableIsIgnoredTest EDT PE
@run main/manual ExceptionFromPrintableIsIgnoredTest EDT RE
Copy link
Contributor

@prrace prrace Jun 8, 2021

Choose a reason for hiding this comment

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

I thought I also explained that the printer keyword means it would only be run if the system has a real printer by virtue of it being set in the jtreg run. You could also do that on a virtual printer if you didn't mind entering the file name

@alitvinv
Copy link
Member Author

alitvinv commented Jun 11, 2021

Hello Phil,

I created the 3rd version of the fix which should address your remarks about the fix and the regression test. Can you please review the 3rd version of the fix (Webrev 03).

Thank you for provision with your position about different aspects of the fix, regression test and the discovered discrepancies with the specification on Windows OS and Linux OS. I absolutely agree that it is incorrect to implement propagation of RTE through "PrinterJob.print()" without wrapping it into "PrinterException", because RTE is not mentioned in the specification for "PrinterJob.print()" method. The 3rd fix version addresses this mistake from previous fix versions.

Perhaps, it is not very significant issue, that on Windows OS and Linux OS RTE from "Printable.print​(Graphics, PageFormat, int)" is propagated, because in this case the user's code does not follow the specification by throwing RTE from "Printable.print​(Graphics, PageFormat, int)". I do not want to investigate this discovered discrepancy with specification on Windows OS and Linux OS in this fix for a little different issue specific to macOS. If it is currently really necessary I can file a bug or 2 bugs in JBS to address the discovered issue on Windows and Linux.

Thank you for giving me the details about "printer" value for "@key" tag in "jtreg" test, because until that moment I mistakenly thought that it was just a marker used for selection of tests marked with it for running and nothing else.

DIFFERENCES INTRODUCED IN THE 3'RD VERSION OF THE FIX:

THE FIX:

  1. "RuntimeException" is wrapped in new "PrinterException" in "CPrinterJob.print(PrintRequestAttributeSet)" to guarantee that the fix can propagate only "PrinterException" from "PrinterJob.print()".

THE REGRESSION TEST:

  1. The test is now fully automatic, "manual" is removed from all JTREG "main" actions. I verified it on MACH and locally.

  2. I addressed your concerns from previous comments and now no exception is thrown from "ExceptionFromPrintableIsIgnoredTest.runTest" method, so there is no any possibility that AWT thread will be crashed by the exception thrown by the test. Now I just execute "PrinterJob.print()" and store any "Throwable" possibly thrown by that method in the instance variable "private volatile Throwable printError" of the test class. And analyze it always on main thread after completion of execution of "ExceptionFromPrintableIsIgnoredTest.runTest" call.

  3. Now the regression test always expects only "PrinterException" to be thrown by "PrinterJob.print()". Since "RuntimeException" is propagated from "PrinterJob.print()" on Windows OS and on Linux OS two test scenarios with "RuntimeException":

  • "@run main ExceptionFromPrintableIsIgnoredTest MAIN RE"
  • "@run main ExceptionFromPrintableIsIgnoredTest EDT RE"

are not executed by the test on Windows and Linux deliberately, otherwise they are failing. This test restriction is implemented by the "if" condition "if ((exceptionType == TestExceptionType.RE) && !isOSX) {".

Hopefully this version of the fix is more acceptable.

Thank you,
Anton

prrace
prrace approved these changes Jun 11, 2021
Copy link
Contributor

@prrace prrace left a comment

Ok. Please file a bug as you mention to bring the other platforms into line.

@openjdk
Copy link

openjdk bot commented Jun 11, 2021

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

8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"

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

  • 49112fa: 8265909: build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home
  • 94d0b0f: 8268565: runtime/records/RedefineRecord.java should be run in driver mode
  • df65237: 8267930: Refine code for loading hsdis library
  • 2e900da: 8268574: ProblemList tests failing due to UseBiasedLocking going away
  • 4fd2a14: 8267556: Enhance class paths check during runtime
  • 8c8422e: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes
  • 1e1039a: 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java
  • 78cb677: 8268539: several serviceability/sa tests should be run in driver mode
  • 7267227: 8268361: Fix the infinite loop in next_line
  • b018c45: 8267630: Start of release updates for JDK 18
  • ... and 42 more: https://git.openjdk.java.net/jdk/compare/81fdeb579adffa45c3adcc28732c69f396d732ce...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 Jun 11, 2021
@alitvinv
Copy link
Member Author

alitvinv commented Jun 14, 2021

@alitvinv
Copy link
Member Author

alitvinv commented Jun 14, 2021

/integrate

@openjdk
Copy link

openjdk bot commented Jun 14, 2021

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

  • c420735: 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow
  • 51f3427: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException
  • ba601b8: 8268520: VirtualSpace::print_on() should be const
  • 1ba4e0c: 8257038: Remove expired flags in JDK 18
  • 90c1034: 8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
  • 5cee23a: 8265518: C1: Intrinsic support for Preconditions.checkIndex
  • a466b49: 8267634: Update --release 17 symbol information for JDK 17 build 26
  • 49112fa: 8265909: build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home
  • 94d0b0f: 8268565: runtime/records/RedefineRecord.java should be run in driver mode
  • df65237: 8267930: Refine code for loading hsdis library
  • ... and 49 more: https://git.openjdk.java.net/jdk/compare/81fdeb579adffa45c3adcc28732c69f396d732ce...master

Your commit was automatically rebased without conflicts.

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

openjdk bot commented Jun 14, 2021

@alitvinv Pushed as commit c0b4407.

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

@alitvinv alitvinv deleted the JDK-8262731 branch Jun 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2d awt integrated
2 participants