RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v4]

[Prasanta Sadhukhan]

On Sun, 4 Aug 2024 21:44:33 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use EventQueue.invokeLater
>
> I think we still have some things to look at here
> 
> (1) The job still gets queued for printing - should it ? Ideally not if there's some thing we can do.
> (2) The "Error during printing" dialog I get after running the test is from macOS not us. Should it happen ?
> (3) There's also an NSException printed which is because a call to CHECK_EXCEPTION thinks
> the pending Java Exception is an error from an upcall made after terminating the print loop.
> 
> Here is the NSException printed for (3) :
> 
> 2024-08-02 13:34:54.360 java[50622:37988054] Java Exception
> 2024-08-02 13:34:54.360 java[50622:37988054] (
>     0   CoreFoundation                      0x00007ff8045ed11a __exceptionPreprocess + 242
>     1   libobjc.A.dylib                     0x00007ff8041120b7 objc_exception_throw + 48
>     2   CoreFoundation                      0x00007ff8045ecf80 +[NSException raise:format:] + 214
>     3   libawt_lwawt.dylib                  0x0000000127355ed8 -[PrinterView complete:] + 552
>     4   libawt_lwawt.dylib                  0x0000000127354050 -[PrintModel safePrintLoop:withEnv:] + 176
>     5   libawt_lwawt.dylib                  0x00000001272f68ef Java_sun_lwawt_macosx_CPrinterJob_printLoop + 3871
>     6   ???                                 0x000000011455ca87 0x0 + 4636134023
> )
>  
> Note it is not a Java Exception, it is an NSException and we log this from JNI_COCOA_EXIT after we catch it.
> Perhaps we should only log this if a debugging flag is set .. but at least in this case it helped me see the problem (3).
> 
> So what's going on with (3)? - I can partly help explain that.
> When we get an unexpected Java Exception from a JNI call and need to bail back up to Java we use NSException to do this.
> Unexpected exceptions mean bad method lookups, eg up calls that create an unexpected exception etc.
> If an NSException is raised Objective-C transfers control to the next "catch" - which is in this case JNI_COCOA_EXIT
> 
> This particular NSException happens because after the printLoop we need to make an up-call from "complete"
> 
>     (*env)->CallVoidMethod(env, fPrinterJob, jf_completePrintLoop);
>     CHECK_EXCEPTION();
> 
> But there's this PrinterAbortException already pending, which means we really should not be making the up-call without clearing it first, which is another issue (#4, or still part of #3 ?)
> 
> After the upcall CHECK_EXCEPTION  sees a pending Java Exception which it supposes is from a problem during the upcall and raises the NSException to "bail" up to the JNI_COCOA_EXIT  where we catch it and l...

@prrace Waiting for your relook on this...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20027#issuecomment-2396361562