Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
On 7/31/2015 6:28 PM, Sergey Bylokhov wrote: On 31.07.15 18:12, Semyon Sadetsky wrote: On 7/31/2015 5:55 PM, Sergey Bylokhov wrote: On 31.07.15 17:29, Semyon Sadetsky wrote: So the test could use one of these java resources inside the native app without any external libraries only using JNI library, right? Since we do not place a binary files to the ws, It will require an xcode and comandline tools. Yes it's standard tools. It is not standard and not installed by default, like on linux for example. And we have binary tests in WS, for example, in DnD test suite there are precompiled images for each platform. And all of them are closed like sqe tests. We are moving closed tests to open repo. Functionality that is involved in native scenarios cannot be tested otherwise. But these scenarios already covered. Then what is the existing test suite name? On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: On 31.07.15 16:51, Semyon Sadetsky wrote: There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
You are right in windows size is limited to 65535 and I tested smaller value. In Linux WM will limit window size to entire of the screen. I will add size assignment as well. --Semyon On 7/31/2015 7:12 PM, Sergey Bylokhov wrote: On 31.07.15 18:00, Semyon Sadetsky wrote: On windows is changed in awt_Window.cpp. WmMove What I see there: (env)->SetIntField(target, AwtComponent::xID, rect.left); (env)->SetIntField(target, AwtComponent::yID, rect.top); Are you talking about size or screen position? Sorry the method name is AwtWIndow::WmSize in awt_Window.cpp, where we update the target and then post the event. The initial window size is preserved on Windows. On OSX it can be different if notifyReshape() is called upon window create. The window size can be change externally by the different reason, so we should always relies on the value which was reported by the system. I don't see any extra issues related to the size currently. --Semyon In general window manager can set a different size/location than we try to set, so we should take a correct values in the callback and update the target component, and after that post event that the bounds was changed. - the utility method was introduced because decorated window can be moved and it is utilized from several places. It is not the case for undecorated window. It can be moved by the window manager. Not sure that container screen position makes any sense for its content size event. Is it specified somewhere? Or can you provide an example when it is necessary? I am not sure. It needs to be checked. --Semyon On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
On 31.07.15 18:00, Semyon Sadetsky wrote: On windows is changed in awt_Window.cpp. WmMove What I see there: (env)->SetIntField(target, AwtComponent::xID, rect.left); (env)->SetIntField(target, AwtComponent::yID, rect.top); Are you talking about size or screen position? Sorry the method name is AwtWIndow::WmSize in awt_Window.cpp, where we update the target and then post the event. The initial window size is preserved on Windows. On OSX it can be different if notifyReshape() is called upon window create. The window size can be change externally by the different reason, so we should always relies on the value which was reported by the system. I don't see any extra issues related to the size currently. --Semyon In general window manager can set a different size/location than we try to set, so we should take a correct values in the callback and update the target component, and after that post event that the bounds was changed. - the utility method was introduced because decorated window can be moved and it is utilized from several places. It is not the case for undecorated window. It can be moved by the window manager. Not sure that container screen position makes any sense for its content size event. Is it specified somewhere? Or can you provide an example when it is necessary? I am not sure. It needs to be checked. --Semyon On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
On 31.07.15 18:12, Semyon Sadetsky wrote: On 7/31/2015 5:55 PM, Sergey Bylokhov wrote: On 31.07.15 17:29, Semyon Sadetsky wrote: So the test could use one of these java resources inside the native app without any external libraries only using JNI library, right? Since we do not place a binary files to the ws, It will require an xcode and comandline tools. Yes it's standard tools. It is not standard and not installed by default, like on linux for example. And we have binary tests in WS, for example, in DnD test suite there are precompiled images for each platform. And all of them are closed like sqe tests. Functionality that is involved in native scenarios cannot be tested otherwise. But these scenarios already covered. On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: On 31.07.15 16:51, Semyon Sadetsky wrote: There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
On 7/31/2015 5:55 PM, Sergey Bylokhov wrote: On 31.07.15 17:29, Semyon Sadetsky wrote: So the test could use one of these java resources inside the native app without any external libraries only using JNI library, right? Since we do not place a binary files to the ws, It will require an xcode and comandline tools. Yes it's standard tools. And we have binary tests in WS, for example, in DnD test suite there are precompiled images for each platform. Functionality that is involved in native scenarios cannot be tested otherwise. On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: On 31.07.15 16:51, Semyon Sadetsky wrote: There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
On windows is changed in awt_Window.cpp. WmMove What I see there: (env)->SetIntField(target, AwtComponent::xID, rect.left); (env)->SetIntField(target, AwtComponent::yID, rect.top); Are you talking about size or screen position? The initial window size is preserved on Windows. On OSX it can be different if notifyReshape() is called upon window create. I don't see any extra issues related to the size currently. --Semyon In general window manager can set a different size/location than we try to set, so we should take a correct values in the callback and update the target component, and after that post event that the bounds was changed. - the utility method was introduced because decorated window can be moved and it is utilized from several places. It is not the case for undecorated window. It can be moved by the window manager. Not sure that container screen position makes any sense for its content size event. Is it specified somewhere? Or can you provide an example when it is necessary? I am not sure. It needs to be checked. --Semyon On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
On 31.07.15 17:29, Semyon Sadetsky wrote: So the test could use one of these java resources inside the native app without any external libraries only using JNI library, right? Since we do not place a binary files to the ws, It will require an xcode and comandline tools. On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: On 31.07.15 16:51, Semyon Sadetsky wrote: There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
On 31.07.15 17:19, Semyon Sadetsky wrote: Hi Sergey, - size remains unchanged on other platforms as well. I'm not sure that there should be exception for window peer on Linux. Do you have any solid info on that? On OSX it is changed in LWWindowPeer.notifyReshape. On windows is changed in awt_Window.cpp. WmMove In general window manager can set a different size/location than we try to set, so we should take a correct values in the callback and update the target component, and after that post event that the bounds was changed. - the utility method was introduced because decorated window can be moved and it is utilized from several places. It is not the case for undecorated window. It can be moved by the window manager. Not sure that container screen position makes any sense for its content size event. Is it specified somewhere? Or can you provide an example when it is necessary? I am not sure. It needs to be checked. --Semyon On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
So the test could use one of these java resources inside the native app without any external libraries only using JNI library, right? On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: On 31.07.15 16:51, Semyon Sadetsky wrote: There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
Hi Sergey, - size remains unchanged on other platforms as well. I'm not sure that there should be exception for window peer on Linux. Do you have any solid info on that? - the utility method was introduced because decorated window can be moved and it is utilized from several places. It is not the case for undecorated window. Not sure that container screen position makes any sense for its content size event. Is it specified somewhere? Or can you provide an example when it is necessary? --Semyon On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
On 31.07.15 16:51, Semyon Sadetsky wrote: There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey.
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
On 31.07.15 10:30, Semyon Sadetsky wrote: JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. -- Best regards, Sergey.
Re: JDK-8015471 "Deadlock or infinit loop in XAWT on Ubuntu 12.04"
I tried to reproduce it, first by starting my app 20 times using this version. Five times I got a gray window. java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) Then the same test on this version, and success all 20 times! java version "1.8.0_60-ea" Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) Now it could be luck that it didnt happen, but I also see what you have done there, by releasing the awtLock in the XPeerWindow while getDefaultConfig goes for the other lock that deadlocked. Thanks for a nice fix! On Thu, Jul 30, 2015 at 6:41 PM, Alexander Zvegintsev < alexander.zvegint...@oracle.com> wrote: > Hi Cristian, > > it looks like that I've already fixed this issue as [1] > Could you please check if the problem is gone with 8u60? > > [1] https://bugs.openjdk.java.net/browse/JDK-8129116 Deadlock with > multimonitor fullscreen windows. > > Thanks, > > Alexander. > > On 07/30/2015 05:23 PM, Christian wrote: > >> Sorry if you dont want bug talk here, I just feel that i need to send >> some information somewhere. I'm talking about >> >> https://bugs.openjdk.java.net/browse/JDK-8015471 >> >> This exact issue happen to me quite frequently. I'm running the below jdk >> version, but it has happened during 1.7.0 jdks also. The bug is closed as >> not reproducable. >> >> java version "1.8.0_45" >> Java(TM) SE Runtime Environment (build 1.8.0_45-b14) >> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) >> >> By running jstack -l on the jvm I see these threads in deadlock with each >> other. >> >> "AWT-EventQueue-0" #21 prio=6 os_prio=0 tid=0x7fa8b05ec800 nid=0x316c >> waiting on condition [0x7fa892e4f000] >>java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0xf064a248> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) >> at >> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) >> at >> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) >> at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) >> at sun.awt.X11GraphicsDevice.getConfigVisualId(Native Method) >> at >> sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:235) >> at >> sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) >> - locked <0xf062a418> (a java.lang.Object) >> at >> javax.swing.RepaintManager.getDoubleBufferMaximumSize(RepaintManager.java:1153) >> at >> javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1035) >> at >> javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1482) >> at javax.swing.RepaintManager.paint(RepaintManager.java:1265) >> at javax.swing.JComponent.paint(JComponent.java:1042) >> at >> java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) >> at >> sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) >> at >> sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) >> at java.awt.Container.paint(Container.java:1973) >> at java.awt.Window.paint(Window.java:3912) >> at javax.swing.RepaintManager$4.run(RepaintManager.java:835) >> at javax.swing.RepaintManager$4.run(RepaintManager.java:807) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> at >> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807) >> at >> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782) >> at >> javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731) >> at javax.swing.RepaintManager.access$1300(RepaintManager.java:64) >> at >> javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720) >> at >> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) >> at java.awt.EventQueue.access$500(EventQueue.java:97) >> at java.awt.EventQueue$3.run(EventQueue.java:709) >> at java.awt.EventQueue$3.run(EventQueue.java:703) >> at java.security.AccessController.d
Re: [9] Review request for 6544871: java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html fails from jdk b09 on windows
The fix looks good to me. Thanks, Alexandr. On 7/30/2015 6:56 PM, Sergey Bylokhov wrote: Looks fine. On 30.07.15 16:13, Yuri Nesterenko wrote: Colleagues, please review this small test-only fix for https://bugs.openjdk.java.net/browse/JDK-6544871 Webrev: http://cr.openjdk.java.net/~yan/6544871/webrev.00 As a result, the test should pass on Windows without stray Ctrl keypress left in the keyboard buffer. Thanks, -yan
[9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon
Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution
JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey.
