Hi Dmitri,
Ok.
I think it will be good to add a testcase (since bug already has a
reproducible test) and since its a print problem, anyone who runs it has
to install printer to verify so no excuse there :-)
or if you can find any other existing testcase which showcase this crash
problem, you can append this bugid to that testcase.
Regards
Prasanta
On 1/19/2017 5:58 PM, dmitry markov wrote:
Hi Prasanta,
Thank you for your feedback.
Actually there are two problems here: JDK-8163889
<https://bugs.openjdk.java.net/browse/JDK-8163889> is devoted to the
crash/assert error and JDK-8173050
<https://bugs.openjdk.java.net/browse/JDK-8173050> which is about
possible lack of support for the images with 'custom' type.
Currently I am trying to address the first problem, (i.e. eliminate
crash and assert errors which take place during printing). So possible
implementations of syncFromCustom(), syncToCustom(), etc. are out of
scope for this fix. They will be investigated under JDK-8173050
<https://bugs.openjdk.java.net/browse/JDK-8173050>.
It is possible to create manual regression test for this problem. Also
the test will require some additional set up steps such as printer
installation and so on. It seems to me that is overhead for person who
runs it. However if you insist on test creation, I will add it.
Thanks,
Dmitry
On 16/01/2017 09:14, Prasanta Sadhukhan wrote:
Hi Dmitri,
Don't you need to implement syncFromCustom() and syncToCustom()?
If not, then it seems you do not need to call this functions from
customPixelsFromJava() and customPixelsToJava() in which case, then
env change/fix will not be needed.
Also, is it not possible to create a regression testcase?
Regards
Prasanta
On 1/14/2017 8:22 PM, Dmitry Markov wrote:
Hello,
Could you review a fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8163889
webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/
Problem description:
Several functions inside ImageSurfaceData.m, (e.g.
customPixelsFromJava(), customPixelsToJava(), etc.) invoke
getJNIEnv() from ThreadUtilities instead of usage corresponding
input parameter. According to the design - getJNIEnv() should be
executed on AppKit thread, but all code related to printing should
NOT run on AppKit thread. So we get the following assert here -
‘CocoaAWT: Not running on AppKit thread 0 when expected.’
Also customPixelsFromJava() and customPixelsToJava() call
OSXOffScreenSurfaceData.syncFromCustom() and
OSXOffScreenSurfaceData.syncToCustom(), but these methods are absent
at Java layer. So when we try to perform such JNI invocation we
experience the crash.
Fix:
It is necessary to eliminate negative effects such as crashes,
native exceptions and assert errors during printing.
Change summary:
- Replaced invocation of getJNIEnv() with usage of corresponding
input parameter.
- Added method stubs to OSXOffScreenSurfaceData.
Thanks,
Dmitry
