Re: [9] Review Request: 8132382 [macosx] Crash during JMC execution

2015-07-31 Thread Semyon Sadetsky



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

2015-07-31 Thread Semyon Sadetsky
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

2015-07-31 Thread Sergey Bylokhov

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

2015-07-31 Thread Sergey Bylokhov

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

2015-07-31 Thread Semyon Sadetsky



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

2015-07-31 Thread Semyon Sadetsky



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

2015-07-31 Thread Sergey Bylokhov

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

2015-07-31 Thread Sergey Bylokhov

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

2015-07-31 Thread Semyon Sadetsky
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

2015-07-31 Thread Semyon Sadetsky

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

2015-07-31 Thread Sergey Bylokhov

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

2015-07-31 Thread Semyon Sadetsky
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

2015-07-31 Thread Sergey Bylokhov
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

2015-07-31 Thread Sergey Bylokhov

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

2015-07-31 Thread Semyon Sadetsky
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

2015-07-31 Thread Sergey Bylokhov

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"

2015-07-31 Thread Christian
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

2015-07-31 Thread Alexander Scherbatiy


 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

2015-07-31 Thread Semyon Sadetsky

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

2015-07-31 Thread Semyon Sadetsky
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.