Re: EventQueue NPE?
Mmm, based on the trail of bugs cited on this thread sounds like it's very much known and dealt with which is great. Unfortunately, for us upgrading in the short term (and especially as far as JDK 8 where one of those is marked fixed) is beyond hopeless so it sounds like we're SOL. Keith Thus spake Alexander Scherbatiy, at Wed, Feb 19, 2014 at 01:09:03PM +0400: > Date: Wed, 19 Feb 2014 13:09:03 +0400 > From: Alexander Scherbatiy > To: Keith Amling > CC: swing-...@openjdk.java.net, "awt-dev@openjdk.java.net" > > Subject: Re: EventQueue NPE? > > On 2/19/2014 8:03 AM, Keith Amling wrote: > >I may be barking up the wrong tree e-mailing an OpenJDK list when I've > >only reproduced this against an Oracle JDK (1.7.0_25, and in particular > >it doesn't reproduce against 1.7.0_21), but the attached file produces > >NPEs [1] via EventQueue.isDispatchThread() fairly regularly with an > >argument of 10 [threads] and can even produce it with just 2 (although > >less often). > This is an interesting exception. I am able to reproduce it with > the JDK 7u51 but > not able to reproduce it with the JDK 8. > >Could you check that the issue is not reproduced on your side > with the latest JDK 8: > > https://urldefense.proofpoint.com/v1/url?u=https://jdk8.java.net/download.html&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=BTdtcPIZXD8V7r6BhVE1Cy1S1ITG2lF8LZPYHbBpv%2B0%3D%0A&m=bNoFskKfZDc6dI4KQbzRlnScA6f5c6N035%2BomhAi8Zc%3D%0A&s=cdc869cdb6dce557a5465ba8a3d3456f6539687ed519fa62f33c56711028e3ea > > > > >We've had even weirder NPEs [2] in the code behind that but I have yet > >to distill them to a repro unfortunately. > We have several reports about this NPE like: > > https://urldefense.proofpoint.com/v1/url?u=https://bugs.openjdk.java.net/browse/JDK-8019272&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=BTdtcPIZXD8V7r6BhVE1Cy1S1ITG2lF8LZPYHbBpv%2B0%3D%0A&m=bNoFskKfZDc6dI4KQbzRlnScA6f5c6N035%2BomhAi8Zc%3D%0A&s=f59a532890c08269ae9600a7e97f8fdc8b538659b054bc66b296ba03fe63f85d > > It should have been already fixed in JDK 7u60 and in the JDK 8. > >Thanks, >Alexandr. > > > >Are either of these known? Is there something we should be doing in our > >rather multi-threaded environment to protect this code? > > > >Keith > > > >[1] E.g.: > > > >>java.lang.NullPointerException > >>at java.awt.EventQueue.isDispatchThread(EventQueue.java:1014) > >>at EQNPE$1.run(EQNPE.java:23) > >[2] Ending in: > > > >>java.lang.NullPointerException > >>at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1011) > >>at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1007) > >>at > >> sun.awt.HeadlessToolkit.getSystemEventQueueImpl(HeadlessToolkit.java:352) > >>at java.awt.Toolkit.getSystemEventQueue(Toolkit.java:1717) > >> >
Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Yes, approved.
...jim
On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
Jim, so this is ready for a push then.
Thanks!
Anton.
On 15.02.2014 5:01, Jim Graham wrote:
I don't need to see an update for that. I didn't read the entire
webrev, but I looked at this one piece of code and if that was the
only thing changed then I think that dealt with the outstanding issues...
...jim
On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
On 14.02.2014 2:52, Jim Graham wrote:
On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
Hi Jim,
Please, look at the update:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
Here I'm correcting the rect after the transform in SG2D:
2123 // In case of negative scale transform, reflect the rect
coords.
2124 if (w < 0) {
2125 w *= -1;
2126 x -= w;
2127 }
2128 if (h < 0) {
2129 h *= -1;
2130 y -= h;
2131 }
The blit direction (dx, dy) remains transformed. Is this the right
behavior from your perspective?
Yes, that looks good. I wonder if the "w *= -1" results in a multiply
byte code whereas "w = -w" would avoid the multiply?
...jim
Jim,
Yes, this indeed results in different byte code instructions (imult &
ineg). Just for curiosity I did some measuring which showed negatioation
worked 10% faster :)
Well, I'll fix it but let me please not send an update...
Thanks!
Anton.
Re: RFR: Allow using a system installed libpng
* Magnus Ihse Bursie [2014-02-20 05:35]: > From my point of view, you can go either way. The changes are mostly > in the build code, except for an include statement. But if the AWT > folks feel more confident that way, sure, you can go via client. Pushed: http://hg.openjdk.java.net/jdk9/client/rev/bfc1c131e540 http://hg.openjdk.java.net/jdk9/client/jdk/rev/5e503831b142 > Just a note: Since you are updating the generated-configure.sh, > someone with access to the closed sources will need to push a > follow-up (the same bug number can be used) with an updated version > of the closed generated-configure.sh. If you go in via the client > forest, I'd prefer if someone from client did that. Please let me know if there is anything I can do to help. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Re: RFR: Allow using a system installed libpng
- Original Message - > Hi Omair, > > > Should I be pushing this to jdk9/dev ? (Or to jdk9/client?) > > If you change client code, then the fix should go to the client repo to > avoid merge conflicts and allow for more manual testing prior to > integrating the changes into the master repo. Perhaps this would be an appropriate point to clarify what constitutes 'client code'? > > -- > best regards, > Anthony > > On 2/19/2014 8:16 PM, Omair Majid wrote: > > * Magnus Ihse Bursie [2014-02-19 06:59]: > >> On 2014-02-17 10:16, Erik Joelsson wrote: > >>> At least to me this looks good, but better let Magnus and Andrew > >>> have their say too. > >> > >> Looks good to me! > > > > Thanks for the reviews, everyone! > > > > I have filed https://bugs.openjdk.java.net/browse/JDK-8035341 to track > > the issue. Can someone please point me some docs that explains what I > > need to do to to this bug once I have pushed the fix? > > > > Should I be pushing this to jdk9/dev ? (Or to jdk9/client?) > > > > Thanks, > > Omair > > > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
The fix looks good for me. Thanks, Alexandr. On 2/20/2014 3:40 PM, dmitry markov wrote: Hello Alexander, Petr, Thank you for review. I agree, the option NSTrackingActiveInActiveApp should be changed to NSTrackingActiveAlways. If it is better to back port the changes for JDK-8012026 under separate fix, I can do it. The difference between this backport and main fix is the changes in CViewPlatformEmbeddedFrame.java. The original changeset integrated into JDK 8 (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1) does not have them, since this file was added later. Thanks, Dmitry On 20/02/2014 14:09, Petr Pchelko wrote: Hello, Alexander. We should either combine these 2 fixes together or back port them separately. I don’t think it’s a good idea to mix different fixes in a single back port. It could be a good to also back port 8012026, but as a separate fix. The back-port and the main fix integrated into JDK 8 are slightly different. Dmitry, could you pleas tell what’s the difference? Thank you. With best regards. Petr. 20 февр. 2014 г., в 1:51 после полудня, Alexander Scherbatiy написал(а): Could you look at the JDK-8012026 fix to investigate, should the NSTrackingActiveInActiveApp option be changed to NSTrackingActiveAlways for the resetTrackingRect method in the AWTView.m file for the backport? http://mail.openjdk.java.net/pipermail/awt-dev/2013-August/005347.html http://cr.openjdk.java.net/~pchelko/8012026/webrev.00/ Thanks, Alexandr. On 2/11/2014 1:46 PM, dmitry markov wrote: Hello, Could you review a back-port of 7171045 to JDK 7u, please? The back-port and the main fix integrated into JDK 8 are slightly different. bug:http://bugs.sun.com/view_bug.do?bug_id=7171045 webrev for jdk7u:http://cr.openjdk.java.net/~dmarkov/7171045/jdk7u/webrev.00/ jdk8 changeset:http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1 technical review for jdk8:http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003238.html Please note: the fix for 7171045 was partly backported to JDK 7u (seehttp://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003376.html for details). However, some problems related to this case still take place on JDK 7u. So it is necessary to backport full changeset integrated into JDK 8. Thanks, Dmitry
Re: [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hello Alexander, Petr, Thank you for review. I agree, the option NSTrackingActiveInActiveApp should be changed to NSTrackingActiveAlways. If it is better to back port the changes for JDK-8012026 under separate fix, I can do it. The difference between this backport and main fix is the changes in CViewPlatformEmbeddedFrame.java. The original changeset integrated into JDK 8 (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1) does not have them, since this file was added later. Thanks, Dmitry ** On 20/02/2014 14:09, Petr Pchelko wrote: Hello, Alexander. We should either combine these 2 fixes together or back port them separately. I don’t think it’s a good idea to mix different fixes in a single back port. It could be a good to also back port 8012026, but as a separate fix. The back-port and the main fix integrated into JDK 8 are slightly different. Dmitry, could you pleas tell what’s the difference? Thank you. With best regards. Petr. 20 февр. 2014 г., в 1:51 после полудня, Alexander Scherbatiy написал(а): Could you look at the JDK-8012026 fix to investigate, should the NSTrackingActiveInActiveApp option be changed to NSTrackingActiveAlways for the resetTrackingRect method in the AWTView.m file for the backport? http://mail.openjdk.java.net/pipermail/awt-dev/2013-August/005347.html http://cr.openjdk.java.net/~pchelko/8012026/webrev.00/ Thanks, Alexandr. On 2/11/2014 1:46 PM, dmitry markov wrote: Hello, Could you review a back-port of 7171045 to JDK 7u, please? The back-port and the main fix integrated into JDK 8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id=7171045 webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7171045/jdk7u/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1 technical review for jdk8: http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003238.html Please note: the fix for 7171045 was partly backported to JDK 7u (see http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003376.html for details). However, some problems related to this case still take place on JDK 7u. So it is necessary to backport full changeset integrated into JDK 8. Thanks, Dmitry
Re: [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hello, Dmitry. > The difference between this backport and main fix is the changes in > CViewPlatformEmbeddedFrame.java. The original changeset integrated into JDK 8 > (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1) does not have > them, since this file was added later. Thank you. > If it is better to back port the changes for JDK-8012026 under separate fix, > I can do it. Could you please do that? It was a CAP bug, so it was quite important. The fix looks good to me. With best regards. Petr. 20 февр. 2014 г., в 3:40 после полудня, dmitry markov написал(а): > Hello Alexander, Petr, > > Thank you for review. > I agree, the option NSTrackingActiveInActiveApp should be changed to > NSTrackingActiveAlways. If it is better to back port the changes for > JDK-8012026 under separate fix, I can do it. > > The difference between this backport and main fix is the changes in > CViewPlatformEmbeddedFrame.java. The original changeset integrated into JDK 8 > (http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1) does not have > them, since this file was added later. > > Thanks, > Dmitry > > On 20/02/2014 14:09, Petr Pchelko wrote: >> Hello, Alexander. >> >> We should either combine these 2 fixes together or back port them >> separately. I don’t think it’s a good idea to mix different fixes in a >> single back port. >> It could be a good to also back port 8012026, but as a separate fix. >> The back-port and the main fix integrated into JDK 8 are slightly different. >> Dmitry, could you pleas tell what’s the difference? >> >> Thank you. >> With best regards. Petr. >> >> >> 20 февр. 2014 г., в 1:51 после полудня, Alexander Scherbatiy >> написал(а): >> >>> Could you look at the JDK-8012026 fix to investigate, should the >>> NSTrackingActiveInActiveApp option be changed to NSTrackingActiveAlways >>> for the resetTrackingRect method in the AWTView.m file for the backport? >>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-August/005347.html >>>http://cr.openjdk.java.net/~pchelko/8012026/webrev.00/ >>> >>> Thanks, >>> Alexandr. >>> >>> On 2/11/2014 1:46 PM, dmitry markov wrote: Hello, Could you review a back-port of 7171045 to JDK 7u, please? The back-port and the main fix integrated into JDK 8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id=7171045 webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7171045/jdk7u/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1 technical review for jdk8: http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003238.html Please note: the fix for 7171045 was partly backported to JDK 7u (see http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003376.html for details). However, some problems related to this case still take place on JDK 7u. So it is necessary to backport full changeset integrated into JDK 8. Thanks, Dmitry >
Re: RFR: Allow using a system installed libpng
On 2014-02-20 09:47, Anthony Petrov wrote: Hi Omair, Should I be pushing this to jdk9/dev ? (Or to jdk9/client?) If you change client code, then the fix should go to the client repo to avoid merge conflicts and allow for more manual testing prior to integrating the changes into the master repo. From my point of view, you can go either way. The changes are mostly in the build code, except for an include statement. But if the AWT folks feel more confident that way, sure, you can go via client. Just a note: Since you are updating the generated-configure.sh, someone with access to the closed sources will need to push a follow-up (the same bug number can be used) with an updated version of the closed generated-configure.sh. If you go in via the client forest, I'd prefer if someone from client did that. /Magnus
Re: [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hello, Alexander. We should either combine these 2 fixes together or back port them separately. I don’t think it’s a good idea to mix different fixes in a single back port. It could be a good to also back port 8012026, but as a separate fix. >> The back-port and the main fix integrated into JDK 8 are slightly different. Dmitry, could you pleas tell what’s the difference? Thank you. With best regards. Petr. 20 февр. 2014 г., в 1:51 после полудня, Alexander Scherbatiy написал(а): > > Could you look at the JDK-8012026 fix to investigate, should the > NSTrackingActiveInActiveApp option be changed to NSTrackingActiveAlways > for the resetTrackingRect method in the AWTView.m file for the backport? > http://mail.openjdk.java.net/pipermail/awt-dev/2013-August/005347.html >http://cr.openjdk.java.net/~pchelko/8012026/webrev.00/ > > Thanks, > Alexandr. > > On 2/11/2014 1:46 PM, dmitry markov wrote: >> Hello, >> >> Could you review a back-port of 7171045 to JDK 7u, please? The back-port and >> the main fix integrated into JDK 8 are slightly different. >> >> bug: http://bugs.sun.com/view_bug.do?bug_id=7171045 >> webrev for jdk7u: >> http://cr.openjdk.java.net/~dmarkov/7171045/jdk7u/webrev.00/ >> jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1 >> technical review for jdk8: >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003238.html >> >> Please note: the fix for 7171045 was partly backported to JDK 7u (see >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003376.html for >> details). However, some problems related to this case still take place on >> JDK 7u. So it is necessary to backport full changeset integrated into JDK 8. >> >> Thanks, >> Dmitry >
Re: [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Could you look at the JDK-8012026 fix to investigate, should the NSTrackingActiveInActiveApp option be changed to NSTrackingActiveAlways for the resetTrackingRect method in the AWTView.m file for the backport? http://mail.openjdk.java.net/pipermail/awt-dev/2013-August/005347.html http://cr.openjdk.java.net/~pchelko/8012026/webrev.00/ Thanks, Alexandr. On 2/11/2014 1:46 PM, dmitry markov wrote: Hello, Could you review a back-port of 7171045 to JDK 7u, please? The back-port and the main fix integrated into JDK 8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id=7171045 webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7171045/jdk7u/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1 technical review for jdk8: http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003238.html Please note: the fix for 7171045 was partly backported to JDK 7u (see http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003376.html for details). However, some problems related to this case still take place on JDK 7u. So it is necessary to backport full changeset integrated into JDK 8. Thanks, Dmitry
Re: RFR: Allow using a system installed libpng
Hi Omair, Should I be pushing this to jdk9/dev ? (Or to jdk9/client?) If you change client code, then the fix should go to the client repo to avoid merge conflicts and allow for more manual testing prior to integrating the changes into the master repo. -- best regards, Anthony On 2/19/2014 8:16 PM, Omair Majid wrote: * Magnus Ihse Bursie [2014-02-19 06:59]: On 2014-02-17 10:16, Erik Joelsson wrote: At least to me this looks good, but better let Magnus and Andrew have their say too. Looks good to me! Thanks for the reviews, everyone! I have filed https://bugs.openjdk.java.net/browse/JDK-8035341 to track the issue. Can someone please point me some docs that explains what I need to do to to this bug once I have pushed the fix? Should I be pushing this to jdk9/dev ? (Or to jdk9/client?) Thanks, Omair
Re: [9] Review Request: JDK-8032960 Running forms URL throws NullPointerException in Javaconsole.
Hi Petr, The fire...() method is now invoked on the Toolkit thread, and I see that the Toolkit.DesktopPropertyChangeSupport.firePropertyChange() will fire the event on the current thread if the toolkit thread belongs to the current app context. The question is: are we 100% sure that on MS Windows the AWT Toolkit thread *never* belongs to a user app context? Even if we're running in an unusual threading mode (like the one for FX where we combine the EDT and the FX toolkit thread)? If this is so, meaning that we always only postEvent() from the T.DPCS.fire...() method on Windows, then I'm fine with the fix. -- best regards, Anthony On 2/19/2014 3:29 PM, Petr Pchelko wrote: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8032960 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8032960/webrev.00/ The problem: The Toolkit thread does not have an AppContext so we can't use EventQueue.invokeLater on it. The solution: Remove invokeLater. This is safe, because the updateProperties is thread safe. The result of this call is a post of a PropertyChangeEvent for each AppContext in the application. The test: Hard to create, because we can't synthesize the WM_SETTINGCHANGE event. Thank you. With best regards. Petr.
