On Sun, 4 Aug 2024 21:44:33 GMT, Phil Race <p...@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
