• Type: Bug
• Component: javafx
• Sub-Component: window-toolkit
• Affected Version: 8

• Priority: P3
• Status: Closed
• Resolution: Fixed

• Submitted: 2013-05-14
• Updated: 2015-06-19
• Resolved: 2013-06-12

JDK 8
8Fixed

Updating "noreg-dev-issue" to "noreg-other". See http://openjdk.java.net/guide/changePlanning.html for the list of valid tags. 19-06-2015 verified using ejdk b119 and ExceptionHandler application, the result is the same both on embedded and desktop "Trapped java.lang.RuntimeException" 06-12-2013 attaching ExceptionHandler application to verify 06-12-2013 I did not provide a reg test for this. Perhaps Artem did for his side of the fix. 09-09-2013 Could you please provide a link to the regression test that can be used to verify the fix? If a regression test is not applicable please add a noreg label as specified on http://openjdk.java.net/guide/changePlanning.html 09-09-2013 pushed to graphics scrum 12-06-2013 webrev out for review 10-06-2013 On 5/14/2013 6:45 PM, David Hill wrote: > On 5/14/13 May 14, 8:33 AM, Artem Ananiev wrote: >> Hi, David, > > Hi Artem, > this may be less of an issue on embedded than other platforms, due > to the way we do native stuff. We should probably review this anyway to > see where Thread.UncaughtExceptionHandler should be used in place of the > prints we have now. Yes, this is basically the idea. printStackTrace() is very hard to intercept > The big difference for embedded is that we keep the application event > thread completely in java, which reduces the # of upcalls by quite a It sounds like there are two issues here: UncaughtExceptionHandler (in Java) and pending JNI exceptions (in native). > bit. That still leaves the question of what to do when an event runnable > generates an exception. Currently for us that would be (LensApplication: > try { > event.dispatch(); > } catch (Exception e) { > e.printStackTrace(); > } What "event" is here? Are application's Runnables wrapped into these events? > That leaves input and window events. > Input event upcalls only enqueue a runnable onto the application event > thread, so we are not calling into user code. I suppose we still could > get an EOM exception on this path. So you don't expect Java exceptions at this step, as real dispatching takes place later. In this case, it makes more sense to use uncaught exception handler when the events are dequeued and dispatched. > Window events are handled mostly in a similar fashion, with the upcall > posting an event on the application event thread - except when we are > already on the event thread, where we execute the runnable directly. > Currently we would just catch and print the exception generated buy the > upcall notification (LensApplication): > private void postEvent(Event e) { > if (Thread.currentThread() == getEventThread()) { > try { > e.dispatch(); > } catch (Exception ex) { > ex.printStackTrace(); > } > } else { > synchronized (eventList) { > eventList.addLast(e); > eventList.notify(); > } > } > } Unrelated question: doesn't such mixed dispatching cause any problems? What if postEvent() is called on the event thread, but the event queue is not empty? It seems that in this case the event will be dispatched out of order. > Daniel has proposed moving most of the window handling logic back up > into Java, but that would not happen for a bit (we need to review this > an see the trade off, and how much we gain). > > So it looks to me that we are mostly covered for exception handling - > except for the chance of an OOM or such for the path where we post on > the event queue. Given your explanation above, I agree. > But what do you think we should be doing with exceptions we are > currently printing ? Forward to the (new to me) > Thread.UncaughtExceptionHandler ? Yes. I introduced a helper method in Application for this purpose: reportException(Throwable). It gets the current thread's (which is likely JavaFX application thread, but not necessarily) exception handler and asks it to handle the exception. Thanks, Artem > Dave >> >> please, forward this email to the engineer who will be responsible for >> this bug. >> >> There are two reasons for I have raised this bug to Critical. First, >> the fix for RT-30239 touched shared code in PlatformImpl, so we don't >> catch all the exceptions in Java, but rely on Glass to do that. >> Second, I looked to Lens native code and didn't find any protection >> against exceptions that may occur in JNI up-calls. On other platforms, >> the pattern was: >> >> env->DoDomeJNIStuff(); >> CHECK_AND_CLEAR_EXCEPTION(env); >> >> where the latter macro/function is expanded to >> >> env->ExceptionDescribe(); >> env->ExceptionClear(); >> >> What RT-30239 does is it changes the macro to get an exception, if any >> occurred, call to Java, and there forward the exception to JavaFX >> event thread's uncaught exception handler. In Lens, I don't see such a >> code that describes/clears JNI exceptions. This can lead to weird >> things, as we can't use JNI with exceptions pending. >> >> Please, let me know if I can help here. >> >> Thanks, >> >> Artem 16-05-2013