From Sergey.Bylokhov at oracle.com  Thu Dec  1 00:18:20 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Dec 2016 03:18:20 +0300
Subject: <AWT Dev> [9] Review request for 8170386: JLightweightFrame
 content can miss paint events on Windows
In-Reply-To: <a1c74f50-3592-2e96-14b5-9f0bad2c7354@oracle.com>
References: <61e9e9d7-250a-2f10-6e45-3ed565e5e642@oracle.com>
	<839ea46a-ccd1-9d69-c1c9-e67d927186c4@oracle.com>
	<ac4ef051-5080-c16b-945e-408701e79f28@oracle.com>
	<e17b146c-04f0-9a5e-99fd-8572f59e7cea@oracle.com>
	<a1c74f50-3592-2e96-14b5-9f0bad2c7354@oracle.com>
Message-ID: <05f522d7-0473-c118-c656-6cc6f41e96da@oracle.com>

On 29.11.16 20:55, Semyon Sadetsky wrote:
>> I doubt how it is possible. If the Paint event was posted from the
>> resize event it will reset the paintPainding to "false" in the
>> WComponentPeer.handleEvent():
>>         switch(id) {
>>             case PaintEvent.PAINT:
>>                 // Got native painting
>>                 paintPending = false;
>>                 // Fallthrough to next statement
>>             case PaintEvent.UPDATE:
>>
>> But since the bug exists I assume that this message wasn't posted and
>> this is the reason why all other UPDATE events are skipped.
> Update is also a PaintEvent.
> Another place that may be affected is endLayout() method which also
> depends on the paintPending flag.

Update is not a paint event, update is an event which posted as a result 
of repaint(), but Paint event is an event which is results of the native 
expose event(usually we have a postPaintEvent() method in peers). Since 
the "paintPending" flag is not reset means that the Paint event is not 
posted(seems that the reason is that we have no native part). And we 
should do this from the WLightweightFramePeer in the same way as we post 
COMPONENT_MOVED/COMPONENT_RESIZED

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Dec  1 00:29:06 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Dec 2016 03:29:06 +0300
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
 dialog should be always on the top when multiple applets with
 APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
Message-ID: <e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>

Hi, Dmitry.
Is it true that the window is disable only if blocked by some other 
window? Is it possible a situation when it can be disabled by 
application and in the same moment can have an enabled child which 
should be moved upfront?

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Thu Dec  1 05:05:28 2016
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 1 Dec 2016 10:35:28 +0530
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
Message-ID: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com>

Also, in gtk3_interface.c, there is this change for color.alpha

2219 color.alpha = 0; in gtk3_get_color_for_flags()

but it is used in
gtk3_get_color_for_state() where it is not initialized

2268     GdkRGBA color;

Regards
Prasanta
On 12/1/2016 1:28 AM, Phil Race wrote:
> Hi Goetz,
>
>>   DataBufferNative.c
>> Using uninitialized value lockInfo.rasBase when calling 
>> DBN_GetPixelPointer.
>
>   75     lockInfo.resBase = NULL;
>
> Did you actually compile this ? The variable is called "rasBase", not 
> "resBase".
>
> And strictly there is no problem since inside  DBN_GetPixelPointer
> the code calls ops->Lock which should initialise this.
> A "rasBase" of 0 isn't really any better than a random one ..
>
> Also I don't see why there's a problem here and not in
> the function immediately following since it is the exact same case.
>
> -phil.
>
> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
>> cc 2d-dev.
>>
>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
>>> Hi Vincent,
>>>
>>> thanks for the quit review!
>>> Good catch that I lost the change to p11_mutex.c ... I had to change
>>> it and it fell out of my patches.
>>> I edited the Last Modified Date, and also updated the copyright 
>>> messages.
>>> New webrev:
>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
>>>
>>> Best regards,
>>>   Goetz.
>>>
>>> (Am I correct that your openJdk name is Vinnie?)
>>>
>>>> -----Original Message-----
>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
>>>> Sent: Mittwoch, 30. November 2016 14:53
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
>>>>
>>>> Hello Goetz,
>>>>
>>>> Please modify the bug summary to reference ECC too.
>>>> Your ECC changes look fine but the ?Last Modified Date? line in the 
>>>> 4 source
>>>> code headers will need to be updated/added.
>>>>
>>>> BTW p11_mutex.c is listed below but appears to be missing from the 
>>>> webrev.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>
>>>>     On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> > wrote:
>>>>
>>>>     Hi,
>>>>
>>>>     I?d like to propose a row of smaller fixes where code is noted 
>>>> down a
>>>> bit questionable.
>>>>     SAP?s quality process requires that we fix these in our 
>>>> internal delivery,
>>>> and I
>>>>     Would like to share my fixes with openJdk.  Some of these fixes 
>>>> are of
>>>> more
>>>>     theoretical nature as how I understand the code paths never 
>>>> allow the
>>>>     problematic situation, but fixing it nevertheless assures that 
>>>> nothing is
>>>>     overseen if the code changes.  Most changes are in libawt_xawt, 
>>>> some
>>>>     are in libsunec.
>>>>
>>>>     I?d appreciate a review:
>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
>>>>
>>>>     Changes in detail:
>>>>
>>>>     awt_InputMethod.c:
>>>>
>>>>     One might overrun the 100 byte fixed-size string 
>>>> statusWindow->status
>>>> by copying text->string.multi_byte without checking the length.
>>>>
>>>>     gtk3_interface.c:
>>>>
>>>>     This less-than-zero comparison of an unsigned value is never true.
>>>>
>>>>     Using uninitialized value color. Field color.alpha is 
>>>> uninitialized.
>>>>     E.g. used at gtk3_interface.c:2287.
>>>>
>>>>     XToolkit.c
>>>>
>>>>     Using uninitialized value ret_timeout.
>>>>     E.g. in XToolkit.c:6809.
>>>>
>>>>     XWindow.c
>>>>
>>>>     Argument is incompatible with corresponding format string 
>>>> conversion.
>>>>
>>>>     splashscreen_sys.c
>>>>
>>>>     Overflowed or truncated value (or a value computed from an
>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
>>>> (double)gdk_scale : native_scale used as return value.
>>>>
>>>>     ec.c
>>>>
>>>>     Using uninitialized value k.dp when calling mp_clear.
>>>>
>>>>     ecdecode.c
>>>>
>>>>     You might overrun the 291 byte fixed-size string genenc by copying
>>>> curveParams->geny without checking the length.
>>>>     Added sanity check before doing the string concatenation.
>>>>
>>>>     ecl_mult.c
>>>>
>>>>     Using uninitialized value kt.flag when calling 
>>>> *group->point_mul. (The
>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
>>>>
>>>>     mpi.c
>>>>
>>>>     Using uninitialized value s. Field s.flag is uninitialized when 
>>>> calling
>>>> s_mp_exch.
>>>>     Using uninitialized value tmp. Field tmp.flag is uninitialized 
>>>> when
>>>> calling s_mp_exch
>>>>     Using uninitialized value t.dp when calling mp_clear.
>>>>
>>>>     p11_mutex.c
>>>>
>>>>     Using uninitialized value *ckpInitArgs. Field 
>>>> ckpInitArgs->flags is
>>>> uninitialized when calling memcpy.
>>>>
>>>>
>>>>     DataBufferNative.c
>>>>
>>>>     Using uninitialized value lockInfo.rasBase when calling
>>>> BN_GetPixelPointer.
>>>>
>>>>     fontpath.c
>>>>
>>>>     You might overrun the 512 byte fixed-size string fontDirPath by 
>>>> copying
>>>> DirP->name[index] without checking the length.
>>>>
>>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161201/3a1ba5cd/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Dec  1 07:28:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 1 Dec 2016 10:28:17 +0300
Subject: <AWT Dev> [9] Review request for 8170386: JLightweightFrame
 content can miss paint events on Windows
In-Reply-To: <05f522d7-0473-c118-c656-6cc6f41e96da@oracle.com>
References: <61e9e9d7-250a-2f10-6e45-3ed565e5e642@oracle.com>
	<839ea46a-ccd1-9d69-c1c9-e67d927186c4@oracle.com>
	<ac4ef051-5080-c16b-945e-408701e79f28@oracle.com>
	<e17b146c-04f0-9a5e-99fd-8572f59e7cea@oracle.com>
	<a1c74f50-3592-2e96-14b5-9f0bad2c7354@oracle.com>
	<05f522d7-0473-c118-c656-6cc6f41e96da@oracle.com>
Message-ID: <fee2611e-2aa8-9b95-a824-1ba0970819f7@oracle.com>

On 01.12.2016 03:18, Sergey Bylokhov wrote:

> On 29.11.16 20:55, Semyon Sadetsky wrote:
>>> I doubt how it is possible. If the Paint event was posted from the
>>> resize event it will reset the paintPainding to "false" in the
>>> WComponentPeer.handleEvent():
>>>         switch(id) {
>>>             case PaintEvent.PAINT:
>>>                 // Got native painting
>>>                 paintPending = false;
>>>                 // Fallthrough to next statement
>>>             case PaintEvent.UPDATE:
>>>
>>> But since the bug exists I assume that this message wasn't posted and
>>> this is the reason why all other UPDATE events are skipped.
>> Update is also a PaintEvent.
>> Another place that may be affected is endLayout() method which also
>> depends on the paintPending flag.
>
> Update is not a paint event, 
There are two types of paint events in java: PaintEvent.PAINT and 
PaintEvent.UPDATE.
> update is an event which posted as a result of repaint(), but Paint 
> event is an event which is results of the native expose event
On windows platform it is called WM_PAINT message.
> (usually we have a postPaintEvent() method in peers). Since the 
> "paintPending" flag is not reset means that the Paint event is not 
> posted(seems that the reason is that we have no native part). And we 
> should do this from the WLightweightFramePeer in the same way as we 
> post COMPONENT_MOVED/COMPONENT_RESIZED
It is already posted on on the end of any layout. Why do you think the 
extra paint event should be added to paint the same layout twice?


From goetz.lindenmaier at sap.com  Thu Dec  1 07:39:03 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 1 Dec 2016 07:39:03 +0000
Subject: <AWT Dev> RFR(M): 8170525: Fix minor issues in awt coding
In-Reply-To: <1D1BCEF7-AD74-4358-8DE3-1073649A55DF@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<1D1BCEF7-AD74-4358-8DE3-1073649A55DF@oracle.com>
Message-ID: <5e2ca37d4f5544ae8eef65ff4aeb9f53@DEROTE13DE08.global.corp.sap>

Hi Vincent, 

I fixed the typo and added a remark to the first line of the bug text.

Best regards,
  Goetz.

> -----Original Message-----
> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> Sent: Mittwoch, 30. November 2016 17:10
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> 
> Note that I have reviewed only the ECC/PKCS11 changes.
> You?ll need a JDK 9 reviewer from awt-dev for your remaining changes.
> 
> There is a minor typo in the commit message: s/ece/ECC
> 
> Also please change the Bug Summary in JBS to indicate that ECC and PKCS11
> changes are also present.
> 
> 
> > On 30 Nov 2016, at 15:41, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> wrote:
> >
> > Hi Vincent,
> >
> > thanks for the quit review!
> > Good catch that I lost the change to p11_mutex.c ... I had to change
> > it and it fell out of my patches.
> 
> That looks fine.
> 
> 
> > I edited the Last Modified Date, and also updated the copyright messages.
> 
> Thanks.
> 
> 
> > New webrev:
> > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >
> > Best regards,
> >  Goetz.
> >
> > (Am I correct that your openJdk name is Vinnie?)
> 
> Yes.
> 
> 
> >
> >> -----Original Message-----
> >> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> >> Sent: Mittwoch, 30. November 2016 14:53
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> >> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> >>
> >> Hello Goetz,
> >>
> >> Please modify the bug summary to reference ECC too.
> >> Your ECC changes look fine but the ?Last Modified Date? line in the 4 source
> >> code headers will need to be updated/added.
> >>
> >> BTW p11_mutex.c is listed below but appears to be missing from the
> webrev.
> >>
> >> Thanks.
> >>
> >>
> >>
> >>
> >> 	On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
> wrote:
> >>
> >> 	Hi,
> >>
> >> 	I?d like to propose a row of smaller fixes where code is noted down a
> >> bit questionable.
> >> 	SAP?s quality process requires that we fix these in our internal delivery,
> >> and I
> >> 	Would like to share my fixes with openJdk.  Some of these fixes are of
> >> more
> >> 	theoretical nature as how I understand the code paths never allow the
> >> 	problematic situation, but fixing it nevertheless assures that nothing is
> >> 	overseen if the code changes.  Most changes are in  libawt_xawt, some
> >> 	are in libsunec.
> >>
> >> 	I?d appreciate a review:
> >> 	http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
> >>
> >> 	Changes in detail:
> >>
> >> 	awt_InputMethod.c:
> >>
> >> 	One might overrun the 100 byte fixed-size string statusWindow->status
> >> by copying text->string.multi_byte without checking the length.
> >>
> >> 	gtk3_interface.c:
> >>
> >> 	This less-than-zero comparison of an unsigned value is never true.
> >>
> >> 	Using uninitialized value color. Field color.alpha is uninitialized.
> >> 	E.g. used at gtk3_interface.c:2287.
> >>
> >> 	XToolkit.c
> >>
> >> 	Using uninitialized value ret_timeout.
> >> 	E.g. in XToolkit.c:6809.
> >>
> >> 	XWindow.c
> >>
> >> 	Argument is incompatible with corresponding format string conversion.
> >>
> >> 	splashscreen_sys.c
> >>
> >> 	Overflowed or truncated value (or a value computed from an
> >> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
> >> (double)gdk_scale : native_scale used as return value.
> >>
> >> 	ec.c
> >>
> >> 	Using uninitialized value k.dp when calling mp_clear.
> >>
> >> 	ecdecode.c
> >>
> >> 	You might overrun the 291 byte fixed-size string genenc by copying
> >> curveParams->geny without checking the length.
> >> 	Added sanity check before doing the string concatenation.
> >>
> >> 	ecl_mult.c
> >>
> >> 	Using uninitialized value kt.flag when calling *group->point_mul. (The
> >> function pointer resolves to ec_GF2m_pt_mul_mont.)
> >>
> >> 	mpi.c
> >>
> >> 	Using uninitialized value s. Field s.flag is uninitialized when calling
> >> s_mp_exch.
> >> 	Using uninitialized value tmp. Field tmp.flag is uninitialized when
> >> calling s_mp_exch
> >> 	Using uninitialized value t.dp when calling mp_clear.
> >>
> >> 	p11_mutex.c
> >>
> >> 	Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
> >> uninitialized when calling memcpy.
> >>
> >>
> >> 	DataBufferNative.c
> >>
> >> 	Using uninitialized value lockInfo.rasBase when calling
> >> BN_GetPixelPointer.
> >>
> >> 	fontpath.c
> >>
> >> 	You might overrun the 512 byte fixed-size string fontDirPath by copying
> >> DirP->name[index] without checking the length.
> >>
> >


From semyon.sadetsky at oracle.com  Thu Dec  1 07:44:40 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 1 Dec 2016 10:44:40 +0300
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com>
Message-ID: <a56a4eb7-a89b-1605-79dc-ff400e6d5483@oracle.com>

yes, this is a potential issue. But actually cases MID,FOCUS,BLACK,WHITE 
are never used.

But the fix is wrong. It should be

color.alpha = 1; --Semyon


On 01.12.2016 08:05, Prasanta Sadhukhan wrote:
>
> Also, in gtk3_interface.c, there is this change for color.alpha
>
> 2219 color.alpha = 0; in gtk3_get_color_for_flags()
> but it is used in
> gtk3_get_color_for_state() where it is not initialized
>
> 2268     GdkRGBA color;
> Regards
> Prasanta
> On 12/1/2016 1:28 AM, Phil Race wrote:
>> Hi Goetz,
>>
>>>   DataBufferNative.c
>>> Using uninitialized value lockInfo.rasBase when calling 
>>> DBN_GetPixelPointer.
>>
>>   75     lockInfo.resBase = NULL;
>>
>> Did you actually compile this ? The variable is called "rasBase", not 
>> "resBase".
>>
>> And strictly there is no problem since inside DBN_GetPixelPointer
>> the code calls ops->Lock which should initialise this.
>> A "rasBase" of 0 isn't really any better than a random one ..
>>
>> Also I don't see why there's a problem here and not in
>> the function immediately following since it is the exact same case.
>>
>> -phil.
>>
>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
>>> cc 2d-dev.
>>>
>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
>>>> Hi Vincent,
>>>>
>>>> thanks for the quit review!
>>>> Good catch that I lost the change to p11_mutex.c ... I had to change
>>>> it and it fell out of my patches.
>>>> I edited the Last Modified Date, and also updated the copyright 
>>>> messages.
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
>>>>
>>>> Best regards,
>>>>   Goetz.
>>>>
>>>> (Am I correct that your openJdk name is Vinnie?)
>>>>
>>>>> -----Original Message-----
>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
>>>>> Sent: Mittwoch, 30. November 2016 14:53
>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
>>>>>
>>>>> Hello Goetz,
>>>>>
>>>>> Please modify the bug summary to reference ECC too.
>>>>> Your ECC changes look fine but the ?Last Modified Date? line in 
>>>>> the 4 source
>>>>> code headers will need to be updated/added.
>>>>>
>>>>> BTW p11_mutex.c is listed below but appears to be missing from the 
>>>>> webrev.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
>>>>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> > 
>>>>> wrote:
>>>>>
>>>>>     Hi,
>>>>>
>>>>>     I?d like to propose a row of smaller fixes where code is noted 
>>>>> down a
>>>>> bit questionable.
>>>>>     SAP?s quality process requires that we fix these in our 
>>>>> internal delivery,
>>>>> and I
>>>>>     Would like to share my fixes with openJdk.  Some of these 
>>>>> fixes are of
>>>>> more
>>>>>     theoretical nature as how I understand the code paths never 
>>>>> allow the
>>>>>     problematic situation, but fixing it nevertheless assures that 
>>>>> nothing is
>>>>>     overseen if the code changes.  Most changes are in 
>>>>> libawt_xawt, some
>>>>>     are in libsunec.
>>>>>
>>>>>     I?d appreciate a review:
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
>>>>>
>>>>>     Changes in detail:
>>>>>
>>>>>     awt_InputMethod.c:
>>>>>
>>>>>     One might overrun the 100 byte fixed-size string 
>>>>> statusWindow->status
>>>>> by copying text->string.multi_byte without checking the length.
>>>>>
>>>>>     gtk3_interface.c:
>>>>>
>>>>>     This less-than-zero comparison of an unsigned value is never 
>>>>> true.
>>>>>
>>>>>     Using uninitialized value color. Field color.alpha is 
>>>>> uninitialized.
>>>>>     E.g. used at gtk3_interface.c:2287.
>>>>>
>>>>>     XToolkit.c
>>>>>
>>>>>     Using uninitialized value ret_timeout.
>>>>>     E.g. in XToolkit.c:6809.
>>>>>
>>>>>     XWindow.c
>>>>>
>>>>>     Argument is incompatible with corresponding format string 
>>>>> conversion.
>>>>>
>>>>>     splashscreen_sys.c
>>>>>
>>>>>     Overflowed or truncated value (or a value computed from an
>>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
>>>>> (double)gdk_scale : native_scale used as return value.
>>>>>
>>>>>     ec.c
>>>>>
>>>>>     Using uninitialized value k.dp when calling mp_clear.
>>>>>
>>>>>     ecdecode.c
>>>>>
>>>>>     You might overrun the 291 byte fixed-size string genenc by 
>>>>> copying
>>>>> curveParams->geny without checking the length.
>>>>>     Added sanity check before doing the string concatenation.
>>>>>
>>>>>     ecl_mult.c
>>>>>
>>>>>     Using uninitialized value kt.flag when calling 
>>>>> *group->point_mul. (The
>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
>>>>>
>>>>>     mpi.c
>>>>>
>>>>>     Using uninitialized value s. Field s.flag is uninitialized 
>>>>> when calling
>>>>> s_mp_exch.
>>>>>     Using uninitialized value tmp. Field tmp.flag is uninitialized 
>>>>> when
>>>>> calling s_mp_exch
>>>>>     Using uninitialized value t.dp when calling mp_clear.
>>>>>
>>>>>     p11_mutex.c
>>>>>
>>>>>     Using uninitialized value *ckpInitArgs. Field 
>>>>> ckpInitArgs->flags is
>>>>> uninitialized when calling memcpy.
>>>>>
>>>>>
>>>>>     DataBufferNative.c
>>>>>
>>>>>     Using uninitialized value lockInfo.rasBase when calling
>>>>> BN_GetPixelPointer.
>>>>>
>>>>>     fontpath.c
>>>>>
>>>>>     You might overrun the 512 byte fixed-size string fontDirPath 
>>>>> by copying
>>>>> DirP->name[index] without checking the length.
>>>>>
>>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161201/bd64f9f8/attachment-0001.html>

From goetz.lindenmaier at sap.com  Thu Dec  1 08:29:57 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 1 Dec 2016 08:29:57 +0000
Subject: <AWT Dev> RFR(M): 8170525: Fix minor issues in awt coding
In-Reply-To: <9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap>
Message-ID: <792ae9be83a0424bbfec6bff1be5a9be@DEROTE13DE08.global.corp.sap>

Hi Christoph, 

I changed the code in fontpath.c to use snprintf, that seems much 
better as the concatenated string is a literal anyways.

Also, I fixed the spaces.

I'll post a new webrev once I'm through all the reviews.

Best regards,
  Goetz.

> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 30. November 2016 20:47
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net; 2d-
> dev at openjdk.java.net; Vincent Ryan <vincent.x.ryan at oracle.com>
> Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding
> 
> Hi Goetz,
> 
> I have some small remarks.
> 
> src/java.desktop/unix/native/common/awt/fontpath.c:
> 
> 247             fontDirPath[sizeof(fontDirPath)-1] = '\0';
> -> you should add spaces left and right of '-'
> 248             strncat(fontDirPath, "/fonts.dir", sizeof(fontDirPath) -
> strlen(fontDirPath));
> -> I think you need to subtract 1 from the 3rd parameter of strncat ('size_t n')
> because man page says:
> "If src contains n or more bytes, strncat() writes n+1 bytes to dest (n from src
> plus the terminating null byte). Therefore, the size of dest must be at least
> strlen(dest)+n+1."
> 
> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c:
> 
> add spaces around '-' in the array index
> 
> The rest looks fine to me.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On
> Behalf
> > Of Lindenmaier, Goetz
> > Sent: Mittwoch, 30. November 2016 16:41
> > To: Vincent Ryan <vincent.x.ryan at oracle.com>
> > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> > Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding
> >
> > Hi Vincent,
> >
> > thanks for the quit review!
> > Good catch that I lost the change to p11_mutex.c ... I had to change
> > it and it fell out of my patches.
> > I edited the Last Modified Date, and also updated the copyright messages.
> > New webrev:
> > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >
> > Best regards,
> >   Goetz.
> >
> > (Am I correct that your openJdk name is Vinnie?)
> >
> > > -----Original Message-----
> > > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> > > Sent: Mittwoch, 30. November 2016 14:53
> > > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> > > Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> > >
> > > Hello Goetz,
> > >
> > > Please modify the bug summary to reference ECC too.
> > > Your ECC changes look fine but the ?Last Modified Date? line in the 4 source
> > > code headers will need to be updated/added.
> > >
> > > BTW p11_mutex.c is listed below but appears to be missing from the
> webrev.
> > >
> > > Thanks.
> > >
> > >
> > >
> > >
> > > 	On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> > > <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
> wrote:
> > >
> > > 	Hi,
> > >
> > > 	I?d like to propose a row of smaller fixes where code is noted down a
> > > bit questionable.
> > > 	SAP?s quality process requires that we fix these in our internal delivery,
> > > and I
> > > 	Would like to share my fixes with openJdk.  Some of these fixes are of
> > > more
> > > 	theoretical nature as how I understand the code paths never allow the
> > > 	problematic situation, but fixing it nevertheless assures that nothing is
> > > 	overseen if the code changes.  Most changes are in  libawt_xawt, some
> > > 	are in libsunec.
> > >
> > > 	I?d appreciate a review:
> > > 	http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
> > >
> > > 	Changes in detail:
> > >
> > > 	awt_InputMethod.c:
> > >
> > > 	One might overrun the 100 byte fixed-size string statusWindow->status
> > > by copying text->string.multi_byte without checking the length.
> > >
> > > 	gtk3_interface.c:
> > >
> > > 	This less-than-zero comparison of an unsigned value is never true.
> > >
> > > 	Using uninitialized value color. Field color.alpha is uninitialized.
> > > 	E.g. used at gtk3_interface.c:2287.
> > >
> > > 	XToolkit.c
> > >
> > > 	Using uninitialized value ret_timeout.
> > > 	E.g. in XToolkit.c:6809.
> > >
> > > 	XWindow.c
> > >
> > > 	Argument is incompatible with corresponding format string conversion.
> > >
> > > 	splashscreen_sys.c
> > >
> > > 	Overflowed or truncated value (or a value computed from an
> > > overflowed or truncated value) (gdk_scale > 0) ? native_scale *
> > > (double)gdk_scale : native_scale used as return value.
> > >
> > > 	ec.c
> > >
> > > 	Using uninitialized value k.dp when calling mp_clear.
> > >
> > > 	ecdecode.c
> > >
> > > 	You might overrun the 291 byte fixed-size string genenc by copying
> > > curveParams->geny without checking the length.
> > > 	Added sanity check before doing the string concatenation.
> > >
> > > 	ecl_mult.c
> > >
> > > 	Using uninitialized value kt.flag when calling *group->point_mul. (The
> > > function pointer resolves to ec_GF2m_pt_mul_mont.)
> > >
> > > 	mpi.c
> > >
> > > 	Using uninitialized value s. Field s.flag is uninitialized when calling
> > > s_mp_exch.
> > > 	Using uninitialized value tmp. Field tmp.flag is uninitialized when
> > > calling s_mp_exch
> > > 	Using uninitialized value t.dp when calling mp_clear.
> > >
> > > 	p11_mutex.c
> > >
> > > 	Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
> > > uninitialized when calling memcpy.
> > >
> > >
> > > 	DataBufferNative.c
> > >
> > > 	Using uninitialized value lockInfo.rasBase when calling
> > > BN_GetPixelPointer.
> > >
> > > 	fontpath.c
> > >
> > > 	You might overrun the 512 byte fixed-size string fontDirPath by copying
> > > DirP->name[index] without checking the length.
> > >


From avik.niyogi at oracle.com  Thu Dec  1 08:50:18 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 1 Dec 2016 14:20:18 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8160536: [macosx]
	Possible regression:
	com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java
In-Reply-To: <d6a1b4c7-fb6e-71df-9223-30d125b44849@oracle.com>
References: <12BA58F1-6C16-43A0-9563-1DFF34B3B812@oracle.com>
	<d6a1b4c7-fb6e-71df-9223-30d125b44849@oracle.com>
Message-ID: <A347CBCE-28D0-4C96-80D1-5CDAAFD97E68@oracle.com>

Fix looks good to me.

With Regards,
Avik Niyogi

> On 29-Nov-2016, at 7:25 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 29.11.16 14:10, Manajit Halder wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8160536
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/8160536/webrev.00/
>> 
>> Issue:
>> Menubar event was not handled in case of key down events
>> 
>> Fix:
>> Added support to handle Menubar event for key down events.
>> 
>> Regards,
>> Manajit
> 
> 
> -- 
> Best regards, Sergey.


From goetz.lindenmaier at sap.com  Thu Dec  1 11:03:07 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 1 Dec 2016 11:03:07 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
Message-ID: <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>

Hi Phil,

> Did you actually compile this ? The variable is called "rasBase", not
> "resBase".
Yes, I compiled it, and I fixed the error, but that was another repo 
I use for the coverity checks.  Somehow it did not find its way into 
the webrev. 

I don't see where ops->Lock() initializes this field. 
ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
to BufImg_GetRasInfo().  I can't look in our code scan results
because the issue is gone after fixing it, that lists the path 
of execution that leads to the issue.
If you are sure this is correct I will remove the initialization,
else I will also put it into the other method.

DBN_GetPixelPointer checks lockInfo->rasBase for NULL and 
does what looks like the error case if it's NULL. Therefore NULL
seemed a good initialization to me.

Best regards,
  Goetz.



> -----Original Message-----
> From: Phil Race [mailto:philip.race at oracle.com]
> Sent: Mittwoch, 30. November 2016 20:59
> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues
> in awt coding
> 
> Hi Goetz,
> 
> >   DataBufferNative.c
> > Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer.
> 
>    75     lockInfo.resBase = NULL;
> 
> Did you actually compile this ? The variable is called "rasBase", not
> "resBase".
> 
> And strictly there is no problem since inside  DBN_GetPixelPointer
> the code calls ops->Lock which should initialise this.
> A "rasBase" of 0 isn't really any better than a random one ..
> 
> Also I don't see why there's a problem here and not in
> the function immediately following since it is the exact same case.
> 
> -phil.
> 
> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> > cc 2d-dev.
> >
> > On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> >> Hi Vincent,
> >>
> >> thanks for the quit review!
> >> Good catch that I lost the change to p11_mutex.c ... I had to change
> >> it and it fell out of my patches.
> >> I edited the Last Modified Date, and also updated the copyright
> >> messages.
> >> New webrev:
> >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >>
> >> Best regards,
> >>   Goetz.
> >>
> >> (Am I correct that your openJdk name is Vinnie?)
> >>
> >>> -----Original Message-----
> >>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> >>> Sent: Mittwoch, 30. November 2016 14:53
> >>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> >>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> >>>
> >>> Hello Goetz,
> >>>
> >>> Please modify the bug summary to reference ECC too.
> >>> Your ECC changes look fine but the ?Last Modified Date? line in the
> >>> 4 source
> >>> code headers will need to be updated/added.
> >>>
> >>> BTW p11_mutex.c is listed below but appears to be missing from the
> >>> webrev.
> >>>
> >>> Thanks.
> >>>
> >>>
> >>>
> >>>
> >>>     On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> >>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
> wrote:
> >>>
> >>>     Hi,
> >>>
> >>>     I?d like to propose a row of smaller fixes where code is noted
> >>> down a
> >>> bit questionable.
> >>>     SAP?s quality process requires that we fix these in our internal
> >>> delivery,
> >>> and I
> >>>     Would like to share my fixes with openJdk.  Some of these fixes
> >>> are of
> >>> more
> >>>     theoretical nature as how I understand the code paths never
> >>> allow the
> >>>     problematic situation, but fixing it nevertheless assures that
> >>> nothing is
> >>>     overseen if the code changes.  Most changes are in libawt_xawt,
> >>> some
> >>>     are in libsunec.
> >>>
> >>>     I?d appreciate a review:
> >>>     http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
> >>>
> >>>     Changes in detail:
> >>>
> >>>     awt_InputMethod.c:
> >>>
> >>>     One might overrun the 100 byte fixed-size string
> >>> statusWindow->status
> >>> by copying text->string.multi_byte without checking the length.
> >>>
> >>>     gtk3_interface.c:
> >>>
> >>>     This less-than-zero comparison of an unsigned value is never true.
> >>>
> >>>     Using uninitialized value color. Field color.alpha is
> >>> uninitialized.
> >>>     E.g. used at gtk3_interface.c:2287.
> >>>
> >>>     XToolkit.c
> >>>
> >>>     Using uninitialized value ret_timeout.
> >>>     E.g. in XToolkit.c:6809.
> >>>
> >>>     XWindow.c
> >>>
> >>>     Argument is incompatible with corresponding format string
> >>> conversion.
> >>>
> >>>     splashscreen_sys.c
> >>>
> >>>     Overflowed or truncated value (or a value computed from an
> >>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
> >>> (double)gdk_scale : native_scale used as return value.
> >>>
> >>>     ec.c
> >>>
> >>>     Using uninitialized value k.dp when calling mp_clear.
> >>>
> >>>     ecdecode.c
> >>>
> >>>     You might overrun the 291 byte fixed-size string genenc by copying
> >>> curveParams->geny without checking the length.
> >>>     Added sanity check before doing the string concatenation.
> >>>
> >>>     ecl_mult.c
> >>>
> >>>     Using uninitialized value kt.flag when calling
> >>> *group->point_mul. (The
> >>> function pointer resolves to ec_GF2m_pt_mul_mont.)
> >>>
> >>>     mpi.c
> >>>
> >>>     Using uninitialized value s. Field s.flag is uninitialized when
> >>> calling
> >>> s_mp_exch.
> >>>     Using uninitialized value tmp. Field tmp.flag is uninitialized when
> >>> calling s_mp_exch
> >>>     Using uninitialized value t.dp when calling mp_clear.
> >>>
> >>>     p11_mutex.c
> >>>
> >>>     Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
> >>> uninitialized when calling memcpy.
> >>>
> >>>
> >>>     DataBufferNative.c
> >>>
> >>>     Using uninitialized value lockInfo.rasBase when calling
> >>> BN_GetPixelPointer.
> >>>
> >>>     fontpath.c
> >>>
> >>>     You might overrun the 512 byte fixed-size string fontDirPath by
> >>> copying
> >>> DirP->name[index] without checking the length.
> >>>
> >>
> >
> >


From goetz.lindenmaier at sap.com  Thu Dec  1 11:10:15 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 1 Dec 2016 11:10:15 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com>
Message-ID: <c90bbb7d3cf54ed79054af151d5e9fd1@DEROTE13DE08.global.corp.sap>

Hi Prasanta, 

good point, I added that too.

Best regards,
  Goetz.

> -----Original Message-----
> From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com]
> Sent: Donnerstag, 1. Dezember 2016 06:05
> To: Phil Race <philip.race at oracle.com>; Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues
> in awt coding
> 
> Also, in gtk3_interface.c, there is this change for color.alpha
> 
> 
> 2219     color.alpha = 0; in gtk3_get_color_for_flags()
> but it is used in
> gtk3_get_color_for_state() where it is not initialized
> 
> 2268     GdkRGBA color;
> Regards
> Prasanta
> 
> On 12/1/2016 1:28 AM, Phil Race wrote:
> 
> 
> 	Hi Goetz,
> 
> 
> 
> 		  DataBufferNative.c
> 		Using uninitialized value lockInfo.rasBase when calling
> DBN_GetPixelPointer.
> 
> 
> 
> 	  75     lockInfo.resBase = NULL;
> 
> 	Did you actually compile this ? The variable is called "rasBase", not
> "resBase".
> 
> 	And strictly there is no problem since inside  DBN_GetPixelPointer
> 	the code calls ops->Lock which should initialise this.
> 	A "rasBase" of 0 isn't really any better than a random one ..
> 
> 	Also I don't see why there's a problem here and not in
> 	the function immediately following since it is the exact same case.
> 
> 	-phil.
> 
> 	On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> 
> 
> 		cc 2d-dev.
> 
> 		On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> 
> 
> 			Hi Vincent,
> 
> 			thanks for the quit review!
> 			Good catch that I lost the change to p11_mutex.c ... I
> had to change
> 			it and it fell out of my patches.
> 			I edited the Last Modified Date, and also updated the
> copyright messages.
> 			New webrev:
> 			http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-
> dev/
> 
> 			Best regards,
> 			  Goetz.
> 
> 			(Am I correct that your openJdk name is Vinnie?)
> 
> 
> 
> 				-----Original Message-----
> 				From: Vincent Ryan
> [mailto:vincent.x.ryan at oracle.com]
> 				Sent: Mittwoch, 30. November 2016 14:53
> 				To: Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> <mailto:goetz.lindenmaier at sap.com>
> 				Cc: awt-dev at openjdk.java.net <mailto:awt-
> dev at openjdk.java.net> ; security-dev at openjdk.java.net <mailto:security-
> dev at openjdk.java.net>
> 				Subject: Re: RFR(M): 8170525: Fix minor issues
> in awt coding
> 
> 				Hello Goetz,
> 
> 				Please modify the bug summary to reference
> ECC too.
> 				Your ECC changes look fine but the ?Last
> Modified Date? line in the 4 source
> 				code headers will need to be updated/added.
> 
> 				BTW p11_mutex.c is listed below but appears
> to be missing from the webrev.
> 
> 				Thanks.
> 
> 
> 
> 
> 				    On 30 Nov 2016, at 13:12, Lindenmaier,
> Goetz
> 				<goetz.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com>  <mailto:goetz.lindenmaier at sap.com>
> <mailto:goetz.lindenmaier at sap.com>  > wrote:
> 
> 				    Hi,
> 
> 				    I?d like to propose a row of smaller fixes
> where code is noted down a
> 				bit questionable.
> 				    SAP?s quality process requires that we fix
> these in our internal delivery,
> 				and I
> 				    Would like to share my fixes with openJdk.
> Some of these fixes are of
> 				more
> 				    theoretical nature as how I understand the
> code paths never allow the
> 				    problematic situation, but fixing it
> nevertheless assures that nothing is
> 				    overseen if the code changes.  Most changes
> are in libawt_xawt, some
> 				    are in libsunec.
> 
> 				    I?d appreciate a review:
> 
> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
> 
> 				    Changes in detail:
> 
> 				    awt_InputMethod.c:
> 
> 				    One might overrun the 100 byte fixed-size
> string statusWindow->status
> 				by copying text->string.multi_byte without
> checking the length.
> 
> 				    gtk3_interface.c:
> 
> 				    This less-than-zero comparison of an
> unsigned value is never true.
> 
> 				    Using uninitialized value color. Field
> color.alpha is uninitialized.
> 				    E.g. used at gtk3_interface.c:2287.
> 
> 				    XToolkit.c
> 
> 				    Using uninitialized value ret_timeout.
> 				    E.g. in XToolkit.c:6809.
> 
> 				    XWindow.c
> 
> 				    Argument is incompatible with
> corresponding format string conversion.
> 
> 				    splashscreen_sys.c
> 
> 				    Overflowed or truncated value (or a value
> computed from an
> 				overflowed or truncated value) (gdk_scale > 0)
> ? native_scale *
> 				(double)gdk_scale : native_scale used as return
> value.
> 
> 				    ec.c
> 
> 				    Using uninitialized value k.dp when calling
> mp_clear.
> 
> 				    ecdecode.c
> 
> 				    You might overrun the 291 byte fixed-size
> string genenc by copying
> 				curveParams->geny without checking the
> length.
> 				    Added sanity check before doing the string
> concatenation.
> 
> 				    ecl_mult.c
> 
> 				    Using uninitialized value kt.flag when calling
> *group->point_mul. (The
> 				function pointer resolves to
> ec_GF2m_pt_mul_mont.)
> 
> 				    mpi.c
> 
> 				    Using uninitialized value s. Field s.flag is
> uninitialized when calling
> 				s_mp_exch.
> 				    Using uninitialized value tmp. Field tmp.flag
> is uninitialized when
> 				calling s_mp_exch
> 				    Using uninitialized value t.dp when calling
> mp_clear.
> 
> 				    p11_mutex.c
> 
> 				    Using uninitialized value *ckpInitArgs. Field
> ckpInitArgs->flags is
> 				uninitialized when calling memcpy.
> 
> 
> 				    DataBufferNative.c
> 
> 				    Using uninitialized value lockInfo.rasBase
> when calling
> 				BN_GetPixelPointer.
> 
> 				    fontpath.c
> 
> 				    You might overrun the 512 byte fixed-size
> string fontDirPath by copying
> 				DirP->name[index] without checking the length.
> 
> 
> 
> 
> 
> 
> 


From goetz.lindenmaier at sap.com  Thu Dec  1 11:13:26 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 1 Dec 2016 11:13:26 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> 
Message-ID: <c0252678c71744a4bd3fa37bdce49b08@DEROTE13DE08.global.corp.sap>

Ah, no, that is just the field that is initialized with the 
Result of  gtk3_get_color_for_flags() why I need to initialize it there.

Best regards,
  Goetz.

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 1. Dezember 2016 12:10
> To: 'Prasanta Sadhukhan' <prasanta.sadhukhan at oracle.com>; Phil Race
> <philip.race at oracle.com>; Sergey Bylokhov <Sergey.Bylokhov at oracle.com>;
> Vincent Ryan <vincent.x.ryan at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> dev at openjdk.java.net
> Subject: RE: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues
> in awt coding
> 
> Hi Prasanta,
> 
> good point, I added that too.
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com]
> > Sent: Donnerstag, 1. Dezember 2016 06:05
> > To: Phil Race <philip.race at oracle.com>; Sergey Bylokhov
> > <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
> > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> > dev at openjdk.java.net
> > Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> issues
> > in awt coding
> >
> > Also, in gtk3_interface.c, there is this change for color.alpha
> >
> >
> > 2219     color.alpha = 0; in gtk3_get_color_for_flags()
> > but it is used in
> > gtk3_get_color_for_state() where it is not initialized
> >
> > 2268     GdkRGBA color;
> > Regards
> > Prasanta
> >
> > On 12/1/2016 1:28 AM, Phil Race wrote:
> >
> >
> > 	Hi Goetz,
> >
> >
> >
> > 		  DataBufferNative.c
> > 		Using uninitialized value lockInfo.rasBase when calling
> > DBN_GetPixelPointer.
> >
> >
> >
> > 	  75     lockInfo.resBase = NULL;
> >
> > 	Did you actually compile this ? The variable is called "rasBase", not
> > "resBase".
> >
> > 	And strictly there is no problem since inside  DBN_GetPixelPointer
> > 	the code calls ops->Lock which should initialise this.
> > 	A "rasBase" of 0 isn't really any better than a random one ..
> >
> > 	Also I don't see why there's a problem here and not in
> > 	the function immediately following since it is the exact same case.
> >
> > 	-phil.
> >
> > 	On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> >
> >
> > 		cc 2d-dev.
> >
> > 		On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> >
> >
> > 			Hi Vincent,
> >
> > 			thanks for the quit review!
> > 			Good catch that I lost the change to p11_mutex.c ... I
> > had to change
> > 			it and it fell out of my patches.
> > 			I edited the Last Modified Date, and also updated the
> > copyright messages.
> > 			New webrev:
> > 			http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-
> > dev/
> >
> > 			Best regards,
> > 			  Goetz.
> >
> > 			(Am I correct that your openJdk name is Vinnie?)
> >
> >
> >
> > 				-----Original Message-----
> > 				From: Vincent Ryan
> > [mailto:vincent.x.ryan at oracle.com]
> > 				Sent: Mittwoch, 30. November 2016 14:53
> > 				To: Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com> <mailto:goetz.lindenmaier at sap.com>
> > 				Cc: awt-dev at openjdk.java.net <mailto:awt-
> > dev at openjdk.java.net> ; security-dev at openjdk.java.net <mailto:security-
> > dev at openjdk.java.net>
> > 				Subject: Re: RFR(M): 8170525: Fix minor issues
> > in awt coding
> >
> > 				Hello Goetz,
> >
> > 				Please modify the bug summary to reference
> > ECC too.
> > 				Your ECC changes look fine but the ?Last
> > Modified Date? line in the 4 source
> > 				code headers will need to be updated/added.
> >
> > 				BTW p11_mutex.c is listed below but appears
> > to be missing from the webrev.
> >
> > 				Thanks.
> >
> >
> >
> >
> > 				    On 30 Nov 2016, at 13:12, Lindenmaier,
> > Goetz
> > 				<goetz.lindenmaier at sap.com
> > <mailto:goetz.lindenmaier at sap.com>  <mailto:goetz.lindenmaier at sap.com>
> > <mailto:goetz.lindenmaier at sap.com>  > wrote:
> >
> > 				    Hi,
> >
> > 				    I?d like to propose a row of smaller fixes
> > where code is noted down a
> > 				bit questionable.
> > 				    SAP?s quality process requires that we fix
> > these in our internal delivery,
> > 				and I
> > 				    Would like to share my fixes with openJdk.
> > Some of these fixes are of
> > 				more
> > 				    theoretical nature as how I understand the
> > code paths never allow the
> > 				    problematic situation, but fixing it
> > nevertheless assures that nothing is
> > 				    overseen if the code changes.  Most changes
> > are in libawt_xawt, some
> > 				    are in libsunec.
> >
> > 				    I?d appreciate a review:
> >
> > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
> >
> > 				    Changes in detail:
> >
> > 				    awt_InputMethod.c:
> >
> > 				    One might overrun the 100 byte fixed-size
> > string statusWindow->status
> > 				by copying text->string.multi_byte without
> > checking the length.
> >
> > 				    gtk3_interface.c:
> >
> > 				    This less-than-zero comparison of an
> > unsigned value is never true.
> >
> > 				    Using uninitialized value color. Field
> > color.alpha is uninitialized.
> > 				    E.g. used at gtk3_interface.c:2287.
> >
> > 				    XToolkit.c
> >
> > 				    Using uninitialized value ret_timeout.
> > 				    E.g. in XToolkit.c:6809.
> >
> > 				    XWindow.c
> >
> > 				    Argument is incompatible with
> > corresponding format string conversion.
> >
> > 				    splashscreen_sys.c
> >
> > 				    Overflowed or truncated value (or a value
> > computed from an
> > 				overflowed or truncated value) (gdk_scale > 0)
> > ? native_scale *
> > 				(double)gdk_scale : native_scale used as return
> > value.
> >
> > 				    ec.c
> >
> > 				    Using uninitialized value k.dp when calling
> > mp_clear.
> >
> > 				    ecdecode.c
> >
> > 				    You might overrun the 291 byte fixed-size
> > string genenc by copying
> > 				curveParams->geny without checking the
> > length.
> > 				    Added sanity check before doing the string
> > concatenation.
> >
> > 				    ecl_mult.c
> >
> > 				    Using uninitialized value kt.flag when calling
> > *group->point_mul. (The
> > 				function pointer resolves to
> > ec_GF2m_pt_mul_mont.)
> >
> > 				    mpi.c
> >
> > 				    Using uninitialized value s. Field s.flag is
> > uninitialized when calling
> > 				s_mp_exch.
> > 				    Using uninitialized value tmp. Field tmp.flag
> > is uninitialized when
> > 				calling s_mp_exch
> > 				    Using uninitialized value t.dp when calling
> > mp_clear.
> >
> > 				    p11_mutex.c
> >
> > 				    Using uninitialized value *ckpInitArgs. Field
> > ckpInitArgs->flags is
> > 				uninitialized when calling memcpy.
> >
> >
> > 				    DataBufferNative.c
> >
> > 				    Using uninitialized value lockInfo.rasBase
> > when calling
> > 				BN_GetPixelPointer.
> >
> > 				    fontpath.c
> >
> > 				    You might overrun the 512 byte fixed-size
> > string fontDirPath by copying
> > 				DirP->name[index] without checking the length.
> >
> >
> >
> >
> >
> >
> >


From philip.race at oracle.com  Thu Dec  1 21:30:58 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 1 Dec 2016 13:30:58 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
Message-ID: <65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>

Sorry. it is
     ops->GetRasInfo(env, ops, lockInfo);
that initialises it ..


That is still before the dereference
Anyway, what was the reason for updating one function, but not the other.
I don't mind the change, but the inconsistency looks odd.

-phil.

On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
> Hi Phil,
>
>> Did you actually compile this ? The variable is called "rasBase", not
>> "resBase".
> Yes, I compiled it, and I fixed the error, but that was another repo
> I use for the coverity checks.  Somehow it did not find its way into
> the webrev.
>
> I don't see where ops->Lock() initializes this field.
> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
> to BufImg_GetRasInfo().  I can't look in our code scan results
> because the issue is gone after fixing it, that lists the path
> of execution that leads to the issue.
> If you are sure this is correct I will remove the initialization,
> else I will also put it into the other method.
>
> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
> does what looks like the error case if it's NULL. Therefore NULL
> seemed a good initialization to me.
>
> Best regards,
>    Goetz.
>
>
>
>> -----Original Message-----
>> From: Phil Race [mailto:philip.race at oracle.com]
>> Sent: Mittwoch, 30. November 2016 20:59
>> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
>> dev at openjdk.java.net
>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues
>> in awt coding
>>
>> Hi Goetz,
>>
>>>    DataBufferNative.c
>>> Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer.
>>     75     lockInfo.resBase = NULL;
>>
>> Did you actually compile this ? The variable is called "rasBase", not
>> "resBase".
>>
>> And strictly there is no problem since inside  DBN_GetPixelPointer
>> the code calls ops->Lock which should initialise this.
>> A "rasBase" of 0 isn't really any better than a random one ..
>>
>> Also I don't see why there's a problem here and not in
>> the function immediately following since it is the exact same case.
>>
>> -phil.
>>
>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
>>> cc 2d-dev.
>>>
>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
>>>> Hi Vincent,
>>>>
>>>> thanks for the quit review!
>>>> Good catch that I lost the change to p11_mutex.c ... I had to change
>>>> it and it fell out of my patches.
>>>> I edited the Last Modified Date, and also updated the copyright
>>>> messages.
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
>>>>
>>>> Best regards,
>>>>    Goetz.
>>>>
>>>> (Am I correct that your openJdk name is Vinnie?)
>>>>
>>>>> -----Original Message-----
>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
>>>>> Sent: Mittwoch, 30. November 2016 14:53
>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
>>>>>
>>>>> Hello Goetz,
>>>>>
>>>>> Please modify the bug summary to reference ECC too.
>>>>> Your ECC changes look fine but the ?Last Modified Date? line in the
>>>>> 4 source
>>>>> code headers will need to be updated/added.
>>>>>
>>>>> BTW p11_mutex.c is listed below but appears to be missing from the
>>>>> webrev.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
>>>>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
>> wrote:
>>>>>      Hi,
>>>>>
>>>>>      I?d like to propose a row of smaller fixes where code is noted
>>>>> down a
>>>>> bit questionable.
>>>>>      SAP?s quality process requires that we fix these in our internal
>>>>> delivery,
>>>>> and I
>>>>>      Would like to share my fixes with openJdk.  Some of these fixes
>>>>> are of
>>>>> more
>>>>>      theoretical nature as how I understand the code paths never
>>>>> allow the
>>>>>      problematic situation, but fixing it nevertheless assures that
>>>>> nothing is
>>>>>      overseen if the code changes.  Most changes are in libawt_xawt,
>>>>> some
>>>>>      are in libsunec.
>>>>>
>>>>>      I?d appreciate a review:
>>>>>      http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
>>>>>
>>>>>      Changes in detail:
>>>>>
>>>>>      awt_InputMethod.c:
>>>>>
>>>>>      One might overrun the 100 byte fixed-size string
>>>>> statusWindow->status
>>>>> by copying text->string.multi_byte without checking the length.
>>>>>
>>>>>      gtk3_interface.c:
>>>>>
>>>>>      This less-than-zero comparison of an unsigned value is never true.
>>>>>
>>>>>      Using uninitialized value color. Field color.alpha is
>>>>> uninitialized.
>>>>>      E.g. used at gtk3_interface.c:2287.
>>>>>
>>>>>      XToolkit.c
>>>>>
>>>>>      Using uninitialized value ret_timeout.
>>>>>      E.g. in XToolkit.c:6809.
>>>>>
>>>>>      XWindow.c
>>>>>
>>>>>      Argument is incompatible with corresponding format string
>>>>> conversion.
>>>>>
>>>>>      splashscreen_sys.c
>>>>>
>>>>>      Overflowed or truncated value (or a value computed from an
>>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
>>>>> (double)gdk_scale : native_scale used as return value.
>>>>>
>>>>>      ec.c
>>>>>
>>>>>      Using uninitialized value k.dp when calling mp_clear.
>>>>>
>>>>>      ecdecode.c
>>>>>
>>>>>      You might overrun the 291 byte fixed-size string genenc by copying
>>>>> curveParams->geny without checking the length.
>>>>>      Added sanity check before doing the string concatenation.
>>>>>
>>>>>      ecl_mult.c
>>>>>
>>>>>      Using uninitialized value kt.flag when calling
>>>>> *group->point_mul. (The
>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
>>>>>
>>>>>      mpi.c
>>>>>
>>>>>      Using uninitialized value s. Field s.flag is uninitialized when
>>>>> calling
>>>>> s_mp_exch.
>>>>>      Using uninitialized value tmp. Field tmp.flag is uninitialized when
>>>>> calling s_mp_exch
>>>>>      Using uninitialized value t.dp when calling mp_clear.
>>>>>
>>>>>      p11_mutex.c
>>>>>
>>>>>      Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
>>>>> uninitialized when calling memcpy.
>>>>>
>>>>>
>>>>>      DataBufferNative.c
>>>>>
>>>>>      Using uninitialized value lockInfo.rasBase when calling
>>>>> BN_GetPixelPointer.
>>>>>
>>>>>      fontpath.c
>>>>>
>>>>>      You might overrun the 512 byte fixed-size string fontDirPath by
>>>>> copying
>>>>> DirP->name[index] without checking the length.
>>>>>
>>>


From goetz.lindenmaier at sap.com  Fri Dec  2 07:58:56 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 2 Dec 2016 07:58:56 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
Message-ID: <81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>

Hi Phil,

I added the initialization to the other function.
http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.04/

I missed that because Coverity didn't complain.
It's not a perfect tool, but it finds sufficient issues
to make it worthwhile.   Is the other awt code fine?

Best regards,
  Goetz.



> -----Original Message-----
> From: Phil Race [mailto:philip.race at oracle.com]
> Sent: Donnerstag, 1. Dezember 2016 22:31
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues
> in awt coding
> 
> Sorry. it is
>      ops->GetRasInfo(env, ops, lockInfo);
> that initialises it ..
> 
> 
> That is still before the dereference
> Anyway, what was the reason for updating one function, but not the other.
> I don't mind the change, but the inconsistency looks odd.
> 
> -phil.
> 
> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
> > Hi Phil,
> >
> >> Did you actually compile this ? The variable is called "rasBase", not
> >> "resBase".
> > Yes, I compiled it, and I fixed the error, but that was another repo
> > I use for the coverity checks.  Somehow it did not find its way into
> > the webrev.
> >
> > I don't see where ops->Lock() initializes this field.
> > ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
> > to BufImg_GetRasInfo().  I can't look in our code scan results
> > because the issue is gone after fixing it, that lists the path
> > of execution that leads to the issue.
> > If you are sure this is correct I will remove the initialization,
> > else I will also put it into the other method.
> >
> > DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
> > does what looks like the error case if it's NULL. Therefore NULL
> > seemed a good initialization to me.
> >
> > Best regards,
> >    Goetz.
> >
> >
> >
> >> -----Original Message-----
> >> From: Phil Race [mailto:philip.race at oracle.com]
> >> Sent: Mittwoch, 30. November 2016 20:59
> >> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
> >> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> >> dev at openjdk.java.net
> >> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> issues
> >> in awt coding
> >>
> >> Hi Goetz,
> >>
> >>>    DataBufferNative.c
> >>> Using uninitialized value lockInfo.rasBase when calling
> DBN_GetPixelPointer.
> >>     75     lockInfo.resBase = NULL;
> >>
> >> Did you actually compile this ? The variable is called "rasBase", not
> >> "resBase".
> >>
> >> And strictly there is no problem since inside  DBN_GetPixelPointer
> >> the code calls ops->Lock which should initialise this.
> >> A "rasBase" of 0 isn't really any better than a random one ..
> >>
> >> Also I don't see why there's a problem here and not in
> >> the function immediately following since it is the exact same case.
> >>
> >> -phil.
> >>
> >> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> >>> cc 2d-dev.
> >>>
> >>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> >>>> Hi Vincent,
> >>>>
> >>>> thanks for the quit review!
> >>>> Good catch that I lost the change to p11_mutex.c ... I had to change
> >>>> it and it fell out of my patches.
> >>>> I edited the Last Modified Date, and also updated the copyright
> >>>> messages.
> >>>> New webrev:
> >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >>>>
> >>>> Best regards,
> >>>>    Goetz.
> >>>>
> >>>> (Am I correct that your openJdk name is Vinnie?)
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> >>>>> Sent: Mittwoch, 30. November 2016 14:53
> >>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> >>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> >>>>>
> >>>>> Hello Goetz,
> >>>>>
> >>>>> Please modify the bug summary to reference ECC too.
> >>>>> Your ECC changes look fine but the ?Last Modified Date? line in the
> >>>>> 4 source
> >>>>> code headers will need to be updated/added.
> >>>>>
> >>>>> BTW p11_mutex.c is listed below but appears to be missing from the
> >>>>> webrev.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>      On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> >>>>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
> >> wrote:
> >>>>>      Hi,
> >>>>>
> >>>>>      I?d like to propose a row of smaller fixes where code is noted
> >>>>> down a
> >>>>> bit questionable.
> >>>>>      SAP?s quality process requires that we fix these in our internal
> >>>>> delivery,
> >>>>> and I
> >>>>>      Would like to share my fixes with openJdk.  Some of these fixes
> >>>>> are of
> >>>>> more
> >>>>>      theoretical nature as how I understand the code paths never
> >>>>> allow the
> >>>>>      problematic situation, but fixing it nevertheless assures that
> >>>>> nothing is
> >>>>>      overseen if the code changes.  Most changes are in libawt_xawt,
> >>>>> some
> >>>>>      are in libsunec.
> >>>>>
> >>>>>      I?d appreciate a review:
> >>>>>      http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
> >>>>>
> >>>>>      Changes in detail:
> >>>>>
> >>>>>      awt_InputMethod.c:
> >>>>>
> >>>>>      One might overrun the 100 byte fixed-size string
> >>>>> statusWindow->status
> >>>>> by copying text->string.multi_byte without checking the length.
> >>>>>
> >>>>>      gtk3_interface.c:
> >>>>>
> >>>>>      This less-than-zero comparison of an unsigned value is never true.
> >>>>>
> >>>>>      Using uninitialized value color. Field color.alpha is
> >>>>> uninitialized.
> >>>>>      E.g. used at gtk3_interface.c:2287.
> >>>>>
> >>>>>      XToolkit.c
> >>>>>
> >>>>>      Using uninitialized value ret_timeout.
> >>>>>      E.g. in XToolkit.c:6809.
> >>>>>
> >>>>>      XWindow.c
> >>>>>
> >>>>>      Argument is incompatible with corresponding format string
> >>>>> conversion.
> >>>>>
> >>>>>      splashscreen_sys.c
> >>>>>
> >>>>>      Overflowed or truncated value (or a value computed from an
> >>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
> >>>>> (double)gdk_scale : native_scale used as return value.
> >>>>>
> >>>>>      ec.c
> >>>>>
> >>>>>      Using uninitialized value k.dp when calling mp_clear.
> >>>>>
> >>>>>      ecdecode.c
> >>>>>
> >>>>>      You might overrun the 291 byte fixed-size string genenc by copying
> >>>>> curveParams->geny without checking the length.
> >>>>>      Added sanity check before doing the string concatenation.
> >>>>>
> >>>>>      ecl_mult.c
> >>>>>
> >>>>>      Using uninitialized value kt.flag when calling
> >>>>> *group->point_mul. (The
> >>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
> >>>>>
> >>>>>      mpi.c
> >>>>>
> >>>>>      Using uninitialized value s. Field s.flag is uninitialized when
> >>>>> calling
> >>>>> s_mp_exch.
> >>>>>      Using uninitialized value tmp. Field tmp.flag is uninitialized when
> >>>>> calling s_mp_exch
> >>>>>      Using uninitialized value t.dp when calling mp_clear.
> >>>>>
> >>>>>      p11_mutex.c
> >>>>>
> >>>>>      Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
> >>>>> uninitialized when calling memcpy.
> >>>>>
> >>>>>
> >>>>>      DataBufferNative.c
> >>>>>
> >>>>>      Using uninitialized value lockInfo.rasBase when calling
> >>>>> BN_GetPixelPointer.
> >>>>>
> >>>>>      fontpath.c
> >>>>>
> >>>>>      You might overrun the 512 byte fixed-size string fontDirPath by
> >>>>> copying
> >>>>> DirP->name[index] without checking the length.
> >>>>>
> >>>


From dmitry.markov at oracle.com  Fri Dec  2 11:16:10 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Fri, 02 Dec 2016 14:16:10 +0300
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
 dialog should be always on the top when multiple applets with
 APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
	<e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
Message-ID: <584157FA.20304@oracle.com>

Hi Sergey,

According to the current implementation we disable a window only when we 
are going to show a modal dialog. However I agree it is not a good idea 
to use isEnabled flag for testing whether the window is blocked or not, 
since such logic is not clear and might be accidentally broken. So I 
have updated the fix; new webrev is located at 
http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/
Summary of changes:
- Added a new function isBlocked() to CPlatformWindow class
- In AWTWindow.m use isBlocked() instead of isEnabled in the cases where 
we have to decide whether the ordering operation is required or not.

Thanks,
Dmitry
On 01/12/2016 03:29, Sergey Bylokhov wrote:
> Hi, Dmitry.
> Is it true that the window is disable only if blocked by some other 
> window? Is it possible a situation when it can be disabled by 
> application and in the same moment can have an enabled child which 
> should be moved upfront?
>


From philip.race at oracle.com  Fri Dec  2 19:45:44 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 2 Dec 2016 11:45:44 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
	<81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
Message-ID: <bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>

I had no other comments, except that it would be good to be sure
that this builds on all relevant platforms .. using the 'blessed' compilers.
If you like I can submit a JPRT job for you based on this patch.

-phil.

On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote:
> Hi Phil,
>
> I added the initialization to the other function.
> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.04/
>
> I missed that because Coverity didn't complain.
> It's not a perfect tool, but it finds sufficient issues
> to make it worthwhile.   Is the other awt code fine?
>
> Best regards,
>    Goetz.
>
>
>
>> -----Original Message-----
>> From: Phil Race [mailto:philip.race at oracle.com]
>> Sent: Donnerstag, 1. Dezember 2016 22:31
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
>> dev at openjdk.java.net
>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues
>> in awt coding
>>
>> Sorry. it is
>>       ops->GetRasInfo(env, ops, lockInfo);
>> that initialises it ..
>>
>>
>> That is still before the dereference
>> Anyway, what was the reason for updating one function, but not the other.
>> I don't mind the change, but the inconsistency looks odd.
>>
>> -phil.
>>
>> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
>>> Hi Phil,
>>>
>>>> Did you actually compile this ? The variable is called "rasBase", not
>>>> "resBase".
>>> Yes, I compiled it, and I fixed the error, but that was another repo
>>> I use for the coverity checks.  Somehow it did not find its way into
>>> the webrev.
>>>
>>> I don't see where ops->Lock() initializes this field.
>>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
>>> to BufImg_GetRasInfo().  I can't look in our code scan results
>>> because the issue is gone after fixing it, that lists the path
>>> of execution that leads to the issue.
>>> If you are sure this is correct I will remove the initialization,
>>> else I will also put it into the other method.
>>>
>>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
>>> does what looks like the error case if it's NULL. Therefore NULL
>>> seemed a good initialization to me.
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Phil Race [mailto:philip.race at oracle.com]
>>>> Sent: Mittwoch, 30. November 2016 20:59
>>>> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
>>>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
>>>> dev at openjdk.java.net
>>>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
>> issues
>>>> in awt coding
>>>>
>>>> Hi Goetz,
>>>>
>>>>>     DataBufferNative.c
>>>>> Using uninitialized value lockInfo.rasBase when calling
>> DBN_GetPixelPointer.
>>>>      75     lockInfo.resBase = NULL;
>>>>
>>>> Did you actually compile this ? The variable is called "rasBase", not
>>>> "resBase".
>>>>
>>>> And strictly there is no problem since inside  DBN_GetPixelPointer
>>>> the code calls ops->Lock which should initialise this.
>>>> A "rasBase" of 0 isn't really any better than a random one ..
>>>>
>>>> Also I don't see why there's a problem here and not in
>>>> the function immediately following since it is the exact same case.
>>>>
>>>> -phil.
>>>>
>>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
>>>>> cc 2d-dev.
>>>>>
>>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
>>>>>> Hi Vincent,
>>>>>>
>>>>>> thanks for the quit review!
>>>>>> Good catch that I lost the change to p11_mutex.c ... I had to change
>>>>>> it and it fell out of my patches.
>>>>>> I edited the Last Modified Date, and also updated the copyright
>>>>>> messages.
>>>>>> New webrev:
>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
>>>>>>
>>>>>> Best regards,
>>>>>>     Goetz.
>>>>>>
>>>>>> (Am I correct that your openJdk name is Vinnie?)
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
>>>>>>> Sent: Mittwoch, 30. November 2016 14:53
>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
>>>>>>>
>>>>>>> Hello Goetz,
>>>>>>>
>>>>>>> Please modify the bug summary to reference ECC too.
>>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in the
>>>>>>> 4 source
>>>>>>> code headers will need to be updated/added.
>>>>>>>
>>>>>>> BTW p11_mutex.c is listed below but appears to be missing from the
>>>>>>> webrev.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>       On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
>>>>>>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
>>>> wrote:
>>>>>>>       Hi,
>>>>>>>
>>>>>>>       I?d like to propose a row of smaller fixes where code is noted
>>>>>>> down a
>>>>>>> bit questionable.
>>>>>>>       SAP?s quality process requires that we fix these in our internal
>>>>>>> delivery,
>>>>>>> and I
>>>>>>>       Would like to share my fixes with openJdk.  Some of these fixes
>>>>>>> are of
>>>>>>> more
>>>>>>>       theoretical nature as how I understand the code paths never
>>>>>>> allow the
>>>>>>>       problematic situation, but fixing it nevertheless assures that
>>>>>>> nothing is
>>>>>>>       overseen if the code changes.  Most changes are in libawt_xawt,
>>>>>>> some
>>>>>>>       are in libsunec.
>>>>>>>
>>>>>>>       I?d appreciate a review:
>>>>>>>       http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/
>>>>>>>
>>>>>>>       Changes in detail:
>>>>>>>
>>>>>>>       awt_InputMethod.c:
>>>>>>>
>>>>>>>       One might overrun the 100 byte fixed-size string
>>>>>>> statusWindow->status
>>>>>>> by copying text->string.multi_byte without checking the length.
>>>>>>>
>>>>>>>       gtk3_interface.c:
>>>>>>>
>>>>>>>       This less-than-zero comparison of an unsigned value is never true.
>>>>>>>
>>>>>>>       Using uninitialized value color. Field color.alpha is
>>>>>>> uninitialized.
>>>>>>>       E.g. used at gtk3_interface.c:2287.
>>>>>>>
>>>>>>>       XToolkit.c
>>>>>>>
>>>>>>>       Using uninitialized value ret_timeout.
>>>>>>>       E.g. in XToolkit.c:6809.
>>>>>>>
>>>>>>>       XWindow.c
>>>>>>>
>>>>>>>       Argument is incompatible with corresponding format string
>>>>>>> conversion.
>>>>>>>
>>>>>>>       splashscreen_sys.c
>>>>>>>
>>>>>>>       Overflowed or truncated value (or a value computed from an
>>>>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
>>>>>>> (double)gdk_scale : native_scale used as return value.
>>>>>>>
>>>>>>>       ec.c
>>>>>>>
>>>>>>>       Using uninitialized value k.dp when calling mp_clear.
>>>>>>>
>>>>>>>       ecdecode.c
>>>>>>>
>>>>>>>       You might overrun the 291 byte fixed-size string genenc by copying
>>>>>>> curveParams->geny without checking the length.
>>>>>>>       Added sanity check before doing the string concatenation.
>>>>>>>
>>>>>>>       ecl_mult.c
>>>>>>>
>>>>>>>       Using uninitialized value kt.flag when calling
>>>>>>> *group->point_mul. (The
>>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
>>>>>>>
>>>>>>>       mpi.c
>>>>>>>
>>>>>>>       Using uninitialized value s. Field s.flag is uninitialized when
>>>>>>> calling
>>>>>>> s_mp_exch.
>>>>>>>       Using uninitialized value tmp. Field tmp.flag is uninitialized when
>>>>>>> calling s_mp_exch
>>>>>>>       Using uninitialized value t.dp when calling mp_clear.
>>>>>>>
>>>>>>>       p11_mutex.c
>>>>>>>
>>>>>>>       Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
>>>>>>> uninitialized when calling memcpy.
>>>>>>>
>>>>>>>
>>>>>>>       DataBufferNative.c
>>>>>>>
>>>>>>>       Using uninitialized value lockInfo.rasBase when calling
>>>>>>> BN_GetPixelPointer.
>>>>>>>
>>>>>>>       fontpath.c
>>>>>>>
>>>>>>>       You might overrun the 512 byte fixed-size string fontDirPath by
>>>>>>> copying
>>>>>>> DirP->name[index] without checking the length.
>>>>>>>


From mik3hall at gmail.com  Sat Dec  3 13:59:57 2016
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 3 Dec 2016 07:59:57 -0600
Subject: <AWT Dev> OS X - Java Native Foundation
Message-ID: <8923AAAE-52F2-4021-9DAC-F90BA4228E83@gmail.com>

I assume OS X java still makes use of the Apple JNF macros,
like?
JNF_CLASS_CACHE
JNF_MEMBER_CACHE

I think these used to be used all over awt.

Does anyone know where documentation for this can still be found online? 
Or would care to email me a copy?

I am looking at some of my own code that used these and can?t find where I have a local copy of the documentation and can?t locate any anywhere online.

Michael Hall




From goetz.lindenmaier at sap.com  Sat Dec  3 17:53:58 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 3 Dec 2016 17:53:58 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
	<81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
	<bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>
Message-ID: <2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap>

Hi Phil, 

that would be great, unfortunately I don't have access to JPRT.

Thanks,
  Goetz.
 
> -----Original Message-----
> From: Phil Race [mailto:philip.race at oracle.com]
> Sent: Friday, December 02, 2016 8:46 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> issues in awt coding
> 
> I had no other comments, except that it would be good to be sure
> that this builds on all relevant platforms .. using the 'blessed' compilers.
> If you like I can submit a JPRT job for you based on this patch.
> 
> -phil.
> 
> On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote:
> > Hi Phil,
> >
> > I added the initialization to the other function.
> > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.04/
> >
> > I missed that because Coverity didn't complain.
> > It's not a perfect tool, but it finds sufficient issues
> > to make it worthwhile.   Is the other awt code fine?
> >
> > Best regards,
> >    Goetz.
> >
> >
> >
> >> -----Original Message-----
> >> From: Phil Race [mailto:philip.race at oracle.com]
> >> Sent: Donnerstag, 1. Dezember 2016 22:31
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
> >> <Sergey.Bylokhov at oracle.com>; Vincent Ryan
> <vincent.x.ryan at oracle.com>
> >> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>;
> security-
> >> dev at openjdk.java.net
> >> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> issues
> >> in awt coding
> >>
> >> Sorry. it is
> >>       ops->GetRasInfo(env, ops, lockInfo);
> >> that initialises it ..
> >>
> >>
> >> That is still before the dereference
> >> Anyway, what was the reason for updating one function, but not the
> other.
> >> I don't mind the change, but the inconsistency looks odd.
> >>
> >> -phil.
> >>
> >> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
> >>> Hi Phil,
> >>>
> >>>> Did you actually compile this ? The variable is called "rasBase", not
> >>>> "resBase".
> >>> Yes, I compiled it, and I fixed the error, but that was another repo
> >>> I use for the coverity checks.  Somehow it did not find its way into
> >>> the webrev.
> >>>
> >>> I don't see where ops->Lock() initializes this field.
> >>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
> >>> to BufImg_GetRasInfo().  I can't look in our code scan results
> >>> because the issue is gone after fixing it, that lists the path
> >>> of execution that leads to the issue.
> >>> If you are sure this is correct I will remove the initialization,
> >>> else I will also put it into the other method.
> >>>
> >>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
> >>> does what looks like the error case if it's NULL. Therefore NULL
> >>> seemed a good initialization to me.
> >>>
> >>> Best regards,
> >>>     Goetz.
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Phil Race [mailto:philip.race at oracle.com]
> >>>> Sent: Mittwoch, 30. November 2016 20:59
> >>>> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier,
> Goetz
> >>>> <goetz.lindenmaier at sap.com>; Vincent Ryan
> <vincent.x.ryan at oracle.com>
> >>>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>;
> security-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> >> issues
> >>>> in awt coding
> >>>>
> >>>> Hi Goetz,
> >>>>
> >>>>>     DataBufferNative.c
> >>>>> Using uninitialized value lockInfo.rasBase when calling
> >> DBN_GetPixelPointer.
> >>>>      75     lockInfo.resBase = NULL;
> >>>>
> >>>> Did you actually compile this ? The variable is called "rasBase", not
> >>>> "resBase".
> >>>>
> >>>> And strictly there is no problem since inside  DBN_GetPixelPointer
> >>>> the code calls ops->Lock which should initialise this.
> >>>> A "rasBase" of 0 isn't really any better than a random one ..
> >>>>
> >>>> Also I don't see why there's a problem here and not in
> >>>> the function immediately following since it is the exact same case.
> >>>>
> >>>> -phil.
> >>>>
> >>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> >>>>> cc 2d-dev.
> >>>>>
> >>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> >>>>>> Hi Vincent,
> >>>>>>
> >>>>>> thanks for the quit review!
> >>>>>> Good catch that I lost the change to p11_mutex.c ... I had to change
> >>>>>> it and it fell out of my patches.
> >>>>>> I edited the Last Modified Date, and also updated the copyright
> >>>>>> messages.
> >>>>>> New webrev:
> >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >>>>>>
> >>>>>> Best regards,
> >>>>>>     Goetz.
> >>>>>>
> >>>>>> (Am I correct that your openJdk name is Vinnie?)
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> >>>>>>> Sent: Mittwoch, 30. November 2016 14:53
> >>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> >>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> >>>>>>>
> >>>>>>> Hello Goetz,
> >>>>>>>
> >>>>>>> Please modify the bug summary to reference ECC too.
> >>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in the
> >>>>>>> 4 source
> >>>>>>> code headers will need to be updated/added.
> >>>>>>>
> >>>>>>> BTW p11_mutex.c is listed below but appears to be missing from
> the
> >>>>>>> webrev.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>       On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> >>>>>>> <goetz.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com> >
> >>>> wrote:
> >>>>>>>       Hi,
> >>>>>>>
> >>>>>>>       I?d like to propose a row of smaller fixes where code is noted
> >>>>>>> down a
> >>>>>>> bit questionable.
> >>>>>>>       SAP?s quality process requires that we fix these in our internal
> >>>>>>> delivery,
> >>>>>>> and I
> >>>>>>>       Would like to share my fixes with openJdk.  Some of these fixes
> >>>>>>> are of
> >>>>>>> more
> >>>>>>>       theoretical nature as how I understand the code paths never
> >>>>>>> allow the
> >>>>>>>       problematic situation, but fixing it nevertheless assures that
> >>>>>>> nothing is
> >>>>>>>       overseen if the code changes.  Most changes are in libawt_xawt,
> >>>>>>> some
> >>>>>>>       are in libsunec.
> >>>>>>>
> >>>>>>>       I?d appreciate a review:
> >>>>>>>       http://cr.openjdk.java.net/~goetz/wr16/8170525-
> awt/webrev.01/
> >>>>>>>
> >>>>>>>       Changes in detail:
> >>>>>>>
> >>>>>>>       awt_InputMethod.c:
> >>>>>>>
> >>>>>>>       One might overrun the 100 byte fixed-size string
> >>>>>>> statusWindow->status
> >>>>>>> by copying text->string.multi_byte without checking the length.
> >>>>>>>
> >>>>>>>       gtk3_interface.c:
> >>>>>>>
> >>>>>>>       This less-than-zero comparison of an unsigned value is never
> true.
> >>>>>>>
> >>>>>>>       Using uninitialized value color. Field color.alpha is
> >>>>>>> uninitialized.
> >>>>>>>       E.g. used at gtk3_interface.c:2287.
> >>>>>>>
> >>>>>>>       XToolkit.c
> >>>>>>>
> >>>>>>>       Using uninitialized value ret_timeout.
> >>>>>>>       E.g. in XToolkit.c:6809.
> >>>>>>>
> >>>>>>>       XWindow.c
> >>>>>>>
> >>>>>>>       Argument is incompatible with corresponding format string
> >>>>>>> conversion.
> >>>>>>>
> >>>>>>>       splashscreen_sys.c
> >>>>>>>
> >>>>>>>       Overflowed or truncated value (or a value computed from an
> >>>>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
> >>>>>>> (double)gdk_scale : native_scale used as return value.
> >>>>>>>
> >>>>>>>       ec.c
> >>>>>>>
> >>>>>>>       Using uninitialized value k.dp when calling mp_clear.
> >>>>>>>
> >>>>>>>       ecdecode.c
> >>>>>>>
> >>>>>>>       You might overrun the 291 byte fixed-size string genenc by
> copying
> >>>>>>> curveParams->geny without checking the length.
> >>>>>>>       Added sanity check before doing the string concatenation.
> >>>>>>>
> >>>>>>>       ecl_mult.c
> >>>>>>>
> >>>>>>>       Using uninitialized value kt.flag when calling
> >>>>>>> *group->point_mul. (The
> >>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
> >>>>>>>
> >>>>>>>       mpi.c
> >>>>>>>
> >>>>>>>       Using uninitialized value s. Field s.flag is uninitialized when
> >>>>>>> calling
> >>>>>>> s_mp_exch.
> >>>>>>>       Using uninitialized value tmp. Field tmp.flag is uninitialized when
> >>>>>>> calling s_mp_exch
> >>>>>>>       Using uninitialized value t.dp when calling mp_clear.
> >>>>>>>
> >>>>>>>       p11_mutex.c
> >>>>>>>
> >>>>>>>       Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
> >>>>>>> uninitialized when calling memcpy.
> >>>>>>>
> >>>>>>>
> >>>>>>>       DataBufferNative.c
> >>>>>>>
> >>>>>>>       Using uninitialized value lockInfo.rasBase when calling
> >>>>>>> BN_GetPixelPointer.
> >>>>>>>
> >>>>>>>       fontpath.c
> >>>>>>>
> >>>>>>>       You might overrun the 512 byte fixed-size string fontDirPath by
> >>>>>>> copying
> >>>>>>> DirP->name[index] without checking the length.
> >>>>>>>


From sergey.bylokhov at oracle.com  Mon Dec  5 02:48:21 2016
From: sergey.bylokhov at oracle.com (serb)
Date: Sun, 4 Dec 2016 18:48:21 -0800
Subject: <AWT Dev> [9] Review request for 8170386: JLightweightFrame
 content can miss paint events on Windows
In-Reply-To: <fee2611e-2aa8-9b95-a824-1ba0970819f7@oracle.com>
References: <61e9e9d7-250a-2f10-6e45-3ed565e5e642@oracle.com>
	<839ea46a-ccd1-9d69-c1c9-e67d927186c4@oracle.com>
	<ac4ef051-5080-c16b-945e-408701e79f28@oracle.com>
	<e17b146c-04f0-9a5e-99fd-8572f59e7cea@oracle.com>
	<a1c74f50-3592-2e96-14b5-9f0bad2c7354@oracle.com>
	<05f522d7-0473-c118-c656-6cc6f41e96da@oracle.com>
	<fee2611e-2aa8-9b95-a824-1ba0970819f7@oracle.com>
Message-ID: <EB8886E1-BB5C-4194-BD4F-C4CC3C5259D4@oracle.com>

>> (usually we have a postPaintEvent() method in peers). Since the "paintPending" flag is not reset means that the Paint event is not posted(seems that the reason is that we have no native part). And we should do this from the WLightweightFramePeer in the same way as we post COMPONENT_MOVED/COMPONENT_RESIZED
> It is already posted on on the end of any layout. Why do you think the extra paint event should be added to paint the same layout twice?

If current code in idk does not work and we have a bug which we are discussing means that this event is not posted? If I missed something, then please clarify the problem.
Note, that if two event of the same type will be posted from a different places they will be merged(coalesced).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161204/646a33c7/attachment.html>

From sergey.bylokhov at oracle.com  Mon Dec  5 02:54:04 2016
From: sergey.bylokhov at oracle.com (serb)
Date: Sun, 4 Dec 2016 18:54:04 -0800
Subject: <AWT Dev> OS X - Java Native Foundation
In-Reply-To: <8923AAAE-52F2-4021-9DAC-F90BA4228E83@gmail.com>
References: <8923AAAE-52F2-4021-9DAC-F90BA4228E83@gmail.com>
Message-ID: <1CF08E12-53B5-4C6C-8A20-2BCF29051B2D@oracle.com>

Hello, Michael.

You can find the source of these macro in the JNFJNI.h which is a part of "Java Native Foundation?:
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/

> 3 ???. 2016 ?., ? 5:59, Michael Hall <mik3hall at gmail.com> ???????(?):
> 
> I assume OS X java still makes use of the Apple JNF macros,
> like?
> JNF_CLASS_CACHE
> JNF_MEMBER_CACHE
> 
> I think these used to be used all over awt.
> 
> Does anyone know where documentation for this can still be found online? 
> Or would care to email me a copy?
> 
> I am looking at some of my own code that used these and can?t find where I have a local copy of the documentation and can?t locate any anywhere online.
> 
> Michael Hall
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161204/59f863ce/attachment.html>

From semyon.sadetsky at oracle.com  Mon Dec  5 07:03:19 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Dec 2016 10:03:19 +0300
Subject: <AWT Dev> [9] Review request for 8170386: JLightweightFrame
 content can miss paint events on Windows
In-Reply-To: <EB8886E1-BB5C-4194-BD4F-C4CC3C5259D4@oracle.com>
References: <61e9e9d7-250a-2f10-6e45-3ed565e5e642@oracle.com>
	<839ea46a-ccd1-9d69-c1c9-e67d927186c4@oracle.com>
	<ac4ef051-5080-c16b-945e-408701e79f28@oracle.com>
	<e17b146c-04f0-9a5e-99fd-8572f59e7cea@oracle.com>
	<a1c74f50-3592-2e96-14b5-9f0bad2c7354@oracle.com>
	<05f522d7-0473-c118-c656-6cc6f41e96da@oracle.com>
	<fee2611e-2aa8-9b95-a824-1ba0970819f7@oracle.com>
	<EB8886E1-BB5C-4194-BD4F-C4CC3C5259D4@oracle.com>
Message-ID: <c29ed659-d5bb-c782-74f6-f4d57deb5164@oracle.com>

On 12/5/2016 5:48 AM, serb wrote:

>>> (usually we have a postPaintEvent() method in peers). Since the 
>>> "paintPending" flag is not reset means that the Paint event is not 
>>> posted(seems that the reason is that we have no native part). And we 
>>> should do this from the WLightweightFramePeer in the same way as we 
>>> post COMPONENT_MOVED/COMPONENT_RESIZED
>> It is already posted on on the end of any layout. Why do you think 
>> the extra paint event should be added to paint the same layout twice?
>
> If current code in idk does not work and we have a bug which we are 
> discussing means that this event is not posted? If I missed something, 
> then please clarify the problem.
 > Paint event may be missed by the JLightweightFrame on Windows 
platform when it is resized consequently to the same size because the 
latter sets paintPainding flag .
"may" means it happens sometimes. It depends on the timings of the 
external resize notification.
> Note, that if two event of the same type will be posted from a 
> different places they will be merged(coalesced).
The coalescing is not issue because it joins repaint areas, so nothing 
will be missed.  The issue is that paint event may be completely ignored 
because of optimization which is not designed for other than native 
platform event scheduling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161205/61899fbc/attachment.html>

From mik3hall at gmail.com  Mon Dec  5 09:08:58 2016
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 5 Dec 2016 03:08:58 -0600
Subject: <AWT Dev> OS X - Java Native Foundation
In-Reply-To: <1CF08E12-53B5-4C6C-8A20-2BCF29051B2D@oracle.com>
References: <8923AAAE-52F2-4021-9DAC-F90BA4228E83@gmail.com>
	<1CF08E12-53B5-4C6C-8A20-2BCF29051B2D@oracle.com>
Message-ID: <1E323B09-AABF-417B-982F-2E5C73A9CAAE@gmail.com>

> On Dec 4, 2016, at 8:54 PM, serb <sergey.bylokhov at oracle.com> wrote:
> 
> Hello, Michael.
> 
> You can find the source of these macro in the JNFJNI.h which is a part of "Java Native Foundation?:
> /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/

Using the header for documentation was suggested on the old Apple java-dev list. 
I just remembered there being html or pdf documentation as well. Maybe I used the html because I can?t find where I have a copy of the pdf. Searching, I do find busted links for a pdf document but not the document itself yet.
I can go by the headers but if anyone did happen to pull a copy of the pdf maybe just email me a copy.

Thanks,

Michael Hall




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161205/cd06cd7a/attachment.html>

From philip.race at oracle.com  Mon Dec  5 18:26:09 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 5 Dec 2016 10:26:09 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
	<81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
	<bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>
	<2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap>
Message-ID: <23a39908-37a6-aa9a-f78f-8f60144cdc02@oracle.com>

I tried it .. and just as well I did. It fails in the crypto code on Mac.

jdk/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c:261:12: error: expression which evaluates to zero treated as a null pointer constant of type 'mp_digit *' (aka 'unsigned long *') [-Werror,-Wnon-literal-null-conversion]
     k.dp = (mp_digit)0;
            ^~~~~~~~~~~
1 error generated.

-phil.



On 12/3/2016 9:53 AM, Lindenmaier, Goetz wrote:
> Hi Phil,
>
> that would be great, unfortunately I don't have access to JPRT.
>
> Thanks,
>    Goetz.
>   
>> -----Original Message-----
>> From: Phil Race [mailto:philip.race at oracle.com]
>> Sent: Friday, December 02, 2016 8:46 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com>
>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
>> issues in awt coding
>>
>> I had no other comments, except that it would be good to be sure
>> that this builds on all relevant platforms .. using the 'blessed' compilers.
>> If you like I can submit a JPRT job for you based on this patch.
>>
>> -phil.
>>
>> On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote:
>>> Hi Phil,
>>>
>>> I added the initialization to the other function.
>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.04/
>>>
>>> I missed that because Coverity didn't complain.
>>> It's not a perfect tool, but it finds sufficient issues
>>> to make it worthwhile.   Is the other awt code fine?
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Phil Race [mailto:philip.race at oracle.com]
>>>> Sent: Donnerstag, 1. Dezember 2016 22:31
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com>; Vincent Ryan
>> <vincent.x.ryan at oracle.com>
>>>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>;
>> security-
>>>> dev at openjdk.java.net
>>>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
>> issues
>>>> in awt coding
>>>>
>>>> Sorry. it is
>>>>        ops->GetRasInfo(env, ops, lockInfo);
>>>> that initialises it ..
>>>>
>>>>
>>>> That is still before the dereference
>>>> Anyway, what was the reason for updating one function, but not the
>> other.
>>>> I don't mind the change, but the inconsistency looks odd.
>>>>
>>>> -phil.
>>>>
>>>> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
>>>>> Hi Phil,
>>>>>
>>>>>> Did you actually compile this ? The variable is called "rasBase", not
>>>>>> "resBase".
>>>>> Yes, I compiled it, and I fixed the error, but that was another repo
>>>>> I use for the coverity checks.  Somehow it did not find its way into
>>>>> the webrev.
>>>>>
>>>>> I don't see where ops->Lock() initializes this field.
>>>>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
>>>>> to BufImg_GetRasInfo().  I can't look in our code scan results
>>>>> because the issue is gone after fixing it, that lists the path
>>>>> of execution that leads to the issue.
>>>>> If you are sure this is correct I will remove the initialization,
>>>>> else I will also put it into the other method.
>>>>>
>>>>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
>>>>> does what looks like the error case if it's NULL. Therefore NULL
>>>>> seemed a good initialization to me.
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Phil Race [mailto:philip.race at oracle.com]
>>>>>> Sent: Mittwoch, 30. November 2016 20:59
>>>>>> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier,
>> Goetz
>>>>>> <goetz.lindenmaier at sap.com>; Vincent Ryan
>> <vincent.x.ryan at oracle.com>
>>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>;
>> security-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
>>>> issues
>>>>>> in awt coding
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>>>      DataBufferNative.c
>>>>>>> Using uninitialized value lockInfo.rasBase when calling
>>>> DBN_GetPixelPointer.
>>>>>>       75     lockInfo.resBase = NULL;
>>>>>>
>>>>>> Did you actually compile this ? The variable is called "rasBase", not
>>>>>> "resBase".
>>>>>>
>>>>>> And strictly there is no problem since inside  DBN_GetPixelPointer
>>>>>> the code calls ops->Lock which should initialise this.
>>>>>> A "rasBase" of 0 isn't really any better than a random one ..
>>>>>>
>>>>>> Also I don't see why there's a problem here and not in
>>>>>> the function immediately following since it is the exact same case.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
>>>>>>> cc 2d-dev.
>>>>>>>
>>>>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
>>>>>>>> Hi Vincent,
>>>>>>>>
>>>>>>>> thanks for the quit review!
>>>>>>>> Good catch that I lost the change to p11_mutex.c ... I had to change
>>>>>>>> it and it fell out of my patches.
>>>>>>>> I edited the Last Modified Date, and also updated the copyright
>>>>>>>> messages.
>>>>>>>> New webrev:
>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>      Goetz.
>>>>>>>>
>>>>>>>> (Am I correct that your openJdk name is Vinnie?)
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
>>>>>>>>> Sent: Mittwoch, 30. November 2016 14:53
>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
>>>>>>>>>
>>>>>>>>> Hello Goetz,
>>>>>>>>>
>>>>>>>>> Please modify the bug summary to reference ECC too.
>>>>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in the
>>>>>>>>> 4 source
>>>>>>>>> code headers will need to be updated/added.
>>>>>>>>>
>>>>>>>>> BTW p11_mutex.c is listed below but appears to be missing from
>> the
>>>>>>>>> webrev.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>        On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
>>>>>>>>> <goetz.lindenmaier at sap.com
>> <mailto:goetz.lindenmaier at sap.com> >
>>>>>> wrote:
>>>>>>>>>        Hi,
>>>>>>>>>
>>>>>>>>>        I?d like to propose a row of smaller fixes where code is noted
>>>>>>>>> down a
>>>>>>>>> bit questionable.
>>>>>>>>>        SAP?s quality process requires that we fix these in our internal
>>>>>>>>> delivery,
>>>>>>>>> and I
>>>>>>>>>        Would like to share my fixes with openJdk.  Some of these fixes
>>>>>>>>> are of
>>>>>>>>> more
>>>>>>>>>        theoretical nature as how I understand the code paths never
>>>>>>>>> allow the
>>>>>>>>>        problematic situation, but fixing it nevertheless assures that
>>>>>>>>> nothing is
>>>>>>>>>        overseen if the code changes.  Most changes are in libawt_xawt,
>>>>>>>>> some
>>>>>>>>>        are in libsunec.
>>>>>>>>>
>>>>>>>>>        I?d appreciate a review:
>>>>>>>>>        http://cr.openjdk.java.net/~goetz/wr16/8170525-
>> awt/webrev.01/
>>>>>>>>>        Changes in detail:
>>>>>>>>>
>>>>>>>>>        awt_InputMethod.c:
>>>>>>>>>
>>>>>>>>>        One might overrun the 100 byte fixed-size string
>>>>>>>>> statusWindow->status
>>>>>>>>> by copying text->string.multi_byte without checking the length.
>>>>>>>>>
>>>>>>>>>        gtk3_interface.c:
>>>>>>>>>
>>>>>>>>>        This less-than-zero comparison of an unsigned value is never
>> true.
>>>>>>>>>        Using uninitialized value color. Field color.alpha is
>>>>>>>>> uninitialized.
>>>>>>>>>        E.g. used at gtk3_interface.c:2287.
>>>>>>>>>
>>>>>>>>>        XToolkit.c
>>>>>>>>>
>>>>>>>>>        Using uninitialized value ret_timeout.
>>>>>>>>>        E.g. in XToolkit.c:6809.
>>>>>>>>>
>>>>>>>>>        XWindow.c
>>>>>>>>>
>>>>>>>>>        Argument is incompatible with corresponding format string
>>>>>>>>> conversion.
>>>>>>>>>
>>>>>>>>>        splashscreen_sys.c
>>>>>>>>>
>>>>>>>>>        Overflowed or truncated value (or a value computed from an
>>>>>>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
>>>>>>>>> (double)gdk_scale : native_scale used as return value.
>>>>>>>>>
>>>>>>>>>        ec.c
>>>>>>>>>
>>>>>>>>>        Using uninitialized value k.dp when calling mp_clear.
>>>>>>>>>
>>>>>>>>>        ecdecode.c
>>>>>>>>>
>>>>>>>>>        You might overrun the 291 byte fixed-size string genenc by
>> copying
>>>>>>>>> curveParams->geny without checking the length.
>>>>>>>>>        Added sanity check before doing the string concatenation.
>>>>>>>>>
>>>>>>>>>        ecl_mult.c
>>>>>>>>>
>>>>>>>>>        Using uninitialized value kt.flag when calling
>>>>>>>>> *group->point_mul. (The
>>>>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
>>>>>>>>>
>>>>>>>>>        mpi.c
>>>>>>>>>
>>>>>>>>>        Using uninitialized value s. Field s.flag is uninitialized when
>>>>>>>>> calling
>>>>>>>>> s_mp_exch.
>>>>>>>>>        Using uninitialized value tmp. Field tmp.flag is uninitialized when
>>>>>>>>> calling s_mp_exch
>>>>>>>>>        Using uninitialized value t.dp when calling mp_clear.
>>>>>>>>>
>>>>>>>>>        p11_mutex.c
>>>>>>>>>
>>>>>>>>>        Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is
>>>>>>>>> uninitialized when calling memcpy.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>        DataBufferNative.c
>>>>>>>>>
>>>>>>>>>        Using uninitialized value lockInfo.rasBase when calling
>>>>>>>>> BN_GetPixelPointer.
>>>>>>>>>
>>>>>>>>>        fontpath.c
>>>>>>>>>
>>>>>>>>>        You might overrun the 512 byte fixed-size string fontDirPath by
>>>>>>>>> copying
>>>>>>>>> DirP->name[index] without checking the length.
>>>>>>>>>


From goetz.lindenmaier at sap.com  Mon Dec  5 22:47:47 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 5 Dec 2016 22:47:47 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <23a39908-37a6-aa9a-f78f-8f60144cdc02@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
	<81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
	<bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>
	<2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap>
	<23a39908-37a6-aa9a-f78f-8f60144cdc02@oracle.com>
Message-ID: <96c15a8dff544fcdb9dd7f86af83523c@DEROTE13DE08.global.corp.sap>

Hi Phil, 

sorry for that! I fixed it, there is an other occurrence, too.
I double checked all the casts, there was also a mp_flags <-> mp_sign wrong in mpi.c
http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.05/
(Also rebased the change)

Best regards,
  Goetz

> -----Original Message-----
> From: Phil Race [mailto:philip.race at oracle.com]
> Sent: Monday, December 05, 2016 7:26 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> issues in awt coding
> 
> I tried it .. and just as well I did. It fails in the crypto code on Mac.
> 
> jdk/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c:261:12: error:
> expression which evaluates to zero treated as a null pointer constant of type
> 'mp_digit *' (aka 'unsigned long *') [-Werror,-Wnon-literal-null-conversion]
>      k.dp = (mp_digit)0;
>             ^~~~~~~~~~~
> 1 error generated.
> 
> -phil.
> 
> 
> 
> On 12/3/2016 9:53 AM, Lindenmaier, Goetz wrote:
> > Hi Phil,
> >
> > that would be great, unfortunately I don't have access to JPRT.
> >
> > Thanks,
> >    Goetz.
> >
> >> -----Original Message-----
> >> From: Phil Race [mailto:philip.race at oracle.com]
> >> Sent: Friday, December 02, 2016 8:46 PM
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey Bylokhov
> >> <Sergey.Bylokhov at oracle.com>
> >> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
> >> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> >> issues in awt coding
> >>
> >> I had no other comments, except that it would be good to be sure
> >> that this builds on all relevant platforms .. using the 'blessed' compilers.
> >> If you like I can submit a JPRT job for you based on this patch.
> >>
> >> -phil.
> >>
> >> On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote:
> >>> Hi Phil,
> >>>
> >>> I added the initialization to the other function.
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.04/
> >>>
> >>> I missed that because Coverity didn't complain.
> >>> It's not a perfect tool, but it finds sufficient issues
> >>> to make it worthwhile.   Is the other awt code fine?
> >>>
> >>> Best regards,
> >>>     Goetz.
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Phil Race [mailto:philip.race at oracle.com]
> >>>> Sent: Donnerstag, 1. Dezember 2016 22:31
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Sergey
> Bylokhov
> >>>> <Sergey.Bylokhov at oracle.com>; Vincent Ryan
> >> <vincent.x.ryan at oracle.com>
> >>>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>;
> >> security-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> >> issues
> >>>> in awt coding
> >>>>
> >>>> Sorry. it is
> >>>>        ops->GetRasInfo(env, ops, lockInfo);
> >>>> that initialises it ..
> >>>>
> >>>>
> >>>> That is still before the dereference
> >>>> Anyway, what was the reason for updating one function, but not the
> >> other.
> >>>> I don't mind the change, but the inconsistency looks odd.
> >>>>
> >>>> -phil.
> >>>>
> >>>> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi Phil,
> >>>>>
> >>>>>> Did you actually compile this ? The variable is called "rasBase", not
> >>>>>> "resBase".
> >>>>> Yes, I compiled it, and I fixed the error, but that was another repo
> >>>>> I use for the coverity checks.  Somehow it did not find its way into
> >>>>> the webrev.
> >>>>>
> >>>>> I don't see where ops->Lock() initializes this field.
> >>>>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
> >>>>> to BufImg_GetRasInfo().  I can't look in our code scan results
> >>>>> because the issue is gone after fixing it, that lists the path
> >>>>> of execution that leads to the issue.
> >>>>> If you are sure this is correct I will remove the initialization,
> >>>>> else I will also put it into the other method.
> >>>>>
> >>>>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
> >>>>> does what looks like the error case if it's NULL. Therefore NULL
> >>>>> seemed a good initialization to me.
> >>>>>
> >>>>> Best regards,
> >>>>>      Goetz.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Phil Race [mailto:philip.race at oracle.com]
> >>>>>> Sent: Mittwoch, 30. November 2016 20:59
> >>>>>> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Lindenmaier,
> >> Goetz
> >>>>>> <goetz.lindenmaier at sap.com>; Vincent Ryan
> >> <vincent.x.ryan at oracle.com>
> >>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>;
> >> security-
> >>>>>> dev at openjdk.java.net
> >>>>>> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix
> minor
> >>>> issues
> >>>>>> in awt coding
> >>>>>>
> >>>>>> Hi Goetz,
> >>>>>>
> >>>>>>>      DataBufferNative.c
> >>>>>>> Using uninitialized value lockInfo.rasBase when calling
> >>>> DBN_GetPixelPointer.
> >>>>>>       75     lockInfo.resBase = NULL;
> >>>>>>
> >>>>>> Did you actually compile this ? The variable is called "rasBase", not
> >>>>>> "resBase".
> >>>>>>
> >>>>>> And strictly there is no problem since inside  DBN_GetPixelPointer
> >>>>>> the code calls ops->Lock which should initialise this.
> >>>>>> A "rasBase" of 0 isn't really any better than a random one ..
> >>>>>>
> >>>>>> Also I don't see why there's a problem here and not in
> >>>>>> the function immediately following since it is the exact same case.
> >>>>>>
> >>>>>> -phil.
> >>>>>>
> >>>>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> >>>>>>> cc 2d-dev.
> >>>>>>>
> >>>>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> >>>>>>>> Hi Vincent,
> >>>>>>>>
> >>>>>>>> thanks for the quit review!
> >>>>>>>> Good catch that I lost the change to p11_mutex.c ... I had to
> change
> >>>>>>>> it and it fell out of my patches.
> >>>>>>>> I edited the Last Modified Date, and also updated the copyright
> >>>>>>>> messages.
> >>>>>>>> New webrev:
> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>      Goetz.
> >>>>>>>>
> >>>>>>>> (Am I correct that your openJdk name is Vinnie?)
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> >>>>>>>>> Sent: Mittwoch, 30. November 2016 14:53
> >>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>>>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
> >>>>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> >>>>>>>>>
> >>>>>>>>> Hello Goetz,
> >>>>>>>>>
> >>>>>>>>> Please modify the bug summary to reference ECC too.
> >>>>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in
> the
> >>>>>>>>> 4 source
> >>>>>>>>> code headers will need to be updated/added.
> >>>>>>>>>
> >>>>>>>>> BTW p11_mutex.c is listed below but appears to be missing from
> >> the
> >>>>>>>>> webrev.
> >>>>>>>>>
> >>>>>>>>> Thanks.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>        On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> >>>>>>>>> <goetz.lindenmaier at sap.com
> >> <mailto:goetz.lindenmaier at sap.com> >
> >>>>>> wrote:
> >>>>>>>>>        Hi,
> >>>>>>>>>
> >>>>>>>>>        I?d like to propose a row of smaller fixes where code is noted
> >>>>>>>>> down a
> >>>>>>>>> bit questionable.
> >>>>>>>>>        SAP?s quality process requires that we fix these in our internal
> >>>>>>>>> delivery,
> >>>>>>>>> and I
> >>>>>>>>>        Would like to share my fixes with openJdk.  Some of these
> fixes
> >>>>>>>>> are of
> >>>>>>>>> more
> >>>>>>>>>        theoretical nature as how I understand the code paths never
> >>>>>>>>> allow the
> >>>>>>>>>        problematic situation, but fixing it nevertheless assures that
> >>>>>>>>> nothing is
> >>>>>>>>>        overseen if the code changes.  Most changes are in
> libawt_xawt,
> >>>>>>>>> some
> >>>>>>>>>        are in libsunec.
> >>>>>>>>>
> >>>>>>>>>        I?d appreciate a review:
> >>>>>>>>>        http://cr.openjdk.java.net/~goetz/wr16/8170525-
> >> awt/webrev.01/
> >>>>>>>>>        Changes in detail:
> >>>>>>>>>
> >>>>>>>>>        awt_InputMethod.c:
> >>>>>>>>>
> >>>>>>>>>        One might overrun the 100 byte fixed-size string
> >>>>>>>>> statusWindow->status
> >>>>>>>>> by copying text->string.multi_byte without checking the length.
> >>>>>>>>>
> >>>>>>>>>        gtk3_interface.c:
> >>>>>>>>>
> >>>>>>>>>        This less-than-zero comparison of an unsigned value is never
> >> true.
> >>>>>>>>>        Using uninitialized value color. Field color.alpha is
> >>>>>>>>> uninitialized.
> >>>>>>>>>        E.g. used at gtk3_interface.c:2287.
> >>>>>>>>>
> >>>>>>>>>        XToolkit.c
> >>>>>>>>>
> >>>>>>>>>        Using uninitialized value ret_timeout.
> >>>>>>>>>        E.g. in XToolkit.c:6809.
> >>>>>>>>>
> >>>>>>>>>        XWindow.c
> >>>>>>>>>
> >>>>>>>>>        Argument is incompatible with corresponding format string
> >>>>>>>>> conversion.
> >>>>>>>>>
> >>>>>>>>>        splashscreen_sys.c
> >>>>>>>>>
> >>>>>>>>>        Overflowed or truncated value (or a value computed from an
> >>>>>>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale *
> >>>>>>>>> (double)gdk_scale : native_scale used as return value.
> >>>>>>>>>
> >>>>>>>>>        ec.c
> >>>>>>>>>
> >>>>>>>>>        Using uninitialized value k.dp when calling mp_clear.
> >>>>>>>>>
> >>>>>>>>>        ecdecode.c
> >>>>>>>>>
> >>>>>>>>>        You might overrun the 291 byte fixed-size string genenc by
> >> copying
> >>>>>>>>> curveParams->geny without checking the length.
> >>>>>>>>>        Added sanity check before doing the string concatenation.
> >>>>>>>>>
> >>>>>>>>>        ecl_mult.c
> >>>>>>>>>
> >>>>>>>>>        Using uninitialized value kt.flag when calling
> >>>>>>>>> *group->point_mul. (The
> >>>>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
> >>>>>>>>>
> >>>>>>>>>        mpi.c
> >>>>>>>>>
> >>>>>>>>>        Using uninitialized value s. Field s.flag is uninitialized when
> >>>>>>>>> calling
> >>>>>>>>> s_mp_exch.
> >>>>>>>>>        Using uninitialized value tmp. Field tmp.flag is uninitialized
> when
> >>>>>>>>> calling s_mp_exch
> >>>>>>>>>        Using uninitialized value t.dp when calling mp_clear.
> >>>>>>>>>
> >>>>>>>>>        p11_mutex.c
> >>>>>>>>>
> >>>>>>>>>        Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags
> is
> >>>>>>>>> uninitialized when calling memcpy.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>        DataBufferNative.c
> >>>>>>>>>
> >>>>>>>>>        Using uninitialized value lockInfo.rasBase when calling
> >>>>>>>>> BN_GetPixelPointer.
> >>>>>>>>>
> >>>>>>>>>        fontpath.c
> >>>>>>>>>
> >>>>>>>>>        You might overrun the 512 byte fixed-size string fontDirPath
> by
> >>>>>>>>> copying
> >>>>>>>>> DirP->name[index] without checking the length.
> >>>>>>>>>


From sergey.bylokhov at oracle.com  Tue Dec  6 01:21:08 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Dec 2016 17:21:08 -0800
Subject: <AWT Dev> [9] Review Request: 4419271 Provide support for
 scrolling-mechanisms of non-mouse input-devices
In-Reply-To: <CANTFZ2hG3BkfBGyccJ0FO-c45R_ZBGZjb7YqOpDKHmW+ArZkeA@mail.gmail.com>
References: <707681e3-0395-b04d-1ab1-b92767267776@oracle.com>
	<865c770d-0169-144a-4bab-5d7a897345ae@oracle.com>
	<CANTFZ2hG3BkfBGyccJ0FO-c45R_ZBGZjb7YqOpDKHmW+ArZkeA@mail.gmail.com>
Message-ID: <1838634B-E343-4279-9652-A5D588FA236C@oracle.com>

Hi, Sergey.
Please take a look to the updated version (the names are updated):
http://cr.openjdk.java.net/~serb/4419271/webrev.03

> 28 ????. 2016 ?., ? 7:01, Sergey Malenkov <malenkov at gmail.com> ???????(?):
> 
> The fix looks good, but we realized that the direction is not always changed.
> For example, Windows from VirtualBox on Mac.
> 
> -    jint scrollLines = 3;
> +    jint toScroll = 3;
> 
> -    UINT platformLines;
> +    UINT platformUnits;
> 
> Also I prefer to use similar names for this variables as before.
> For example, scrollUnits instead of toScroll
> 
> 
> 
> On Thu, Nov 24, 2016 at 4:32 PM, Alexandr Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>> 
>> The fix looks good to me.
>> 
>> Thanks,
>> Alexandr.
>> 
>> 
>> On 11/23/2016 5:20 PM, Sergey Bylokhov wrote:
>>> 
>>> Hello.
>>> 
>>> Please review the fix for jdk9.
>>> 
>>> Support of WM_MOUSEHWHEEL for Swing was added (AWT components were not
>>> touched), which mostly the code symmetric to the WM_MOUSEWHEEL, except that
>>> I changed the direction to align it in Swing and OS. It seems that this
>>> functionality does not work on linux as well, at least I was not able to
>>> enable it. Will file a separate bug for jdk on linux.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4419271
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/4419271/webrev.02
>>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Sergey A. Malenkov


From philip.race at oracle.com  Tue Dec  6 03:20:42 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 05 Dec 2016 19:20:42 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <96c15a8dff544fcdb9dd7f86af83523c@DEROTE13DE08.global.corp.sap>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
	<81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
	<bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>
	<2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap>
	<23a39908-37a6-aa9a-f78f-8f60144cdc02@oracle.com>
	<96c15a8dff544fcdb9dd7f86af83523c@DEROTE13DE08.global.corp.sap>
Message-ID: <58462E8A.6090508@oracle.com>

I didn't eyeball what you changed but JPRT is now happy.
The build passes on all platforms...

-phil.

On 12/5/16, 2:47 PM, Lindenmaier, Goetz wrote:
> Hi Phil,
>
> sorry for that! I fixed it, there is an other occurrence, too.
> I double checked all the casts, there was also a mp_flags<->  mp_sign wrong in mpi.c
> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.05/
> (Also rebased the change)
>
> Best regards,
>    Goetz
>
>> -----Original Message-----
>> From: Phil Race [mailto:philip.race at oracle.com]
>> Sent: Monday, December 05, 2016 7:26 PM
>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>; Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com>
>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>
>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix minor
>> issues in awt coding
>>
>> I tried it .. and just as well I did. It fails in the crypto code on Mac.
>>
>> jdk/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c:261:12: error:
>> expression which evaluates to zero treated as a null pointer constant of type
>> 'mp_digit *' (aka 'unsigned long *') [-Werror,-Wnon-literal-null-conversion]
>>       k.dp = (mp_digit)0;
>>              ^~~~~~~~~~~
>> 1 error generated.
>>
>> -phil.
>>
>>
>>
>> On 12/3/2016 9:53 AM, Lindenmaier, Goetz wrote:
>>> Hi Phil,
>>>
>>> that would be great, unfortunately I don't have access to JPRT.
>>>
>>> Thanks,
>>>     Goetz.
>>>
>>>> -----Original Message-----
>>>> From: Phil Race [mailto:philip.race at oracle.com]
>>>> Sent: Friday, December 02, 2016 8:46 PM
>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>; Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com>
>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>
>>>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix minor
>>>> issues in awt coding
>>>>
>>>> I had no other comments, except that it would be good to be sure
>>>> that this builds on all relevant platforms .. using the 'blessed' compilers.
>>>> If you like I can submit a JPRT job for you based on this patch.
>>>>
>>>> -phil.
>>>>
>>>> On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote:
>>>>> Hi Phil,
>>>>>
>>>>> I added the initialization to the other function.
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.04/
>>>>>
>>>>> I missed that because Coverity didn't complain.
>>>>> It's not a perfect tool, but it finds sufficient issues
>>>>> to make it worthwhile.   Is the other awt code fine?
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Phil Race [mailto:philip.race at oracle.com]
>>>>>> Sent: Donnerstag, 1. Dezember 2016 22:31
>>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>; Sergey
>> Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com>; Vincent Ryan
>>>> <vincent.x.ryan at oracle.com>
>>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>;
>>>> security-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix minor
>>>> issues
>>>>>> in awt coding
>>>>>>
>>>>>> Sorry. it is
>>>>>>         ops->GetRasInfo(env, ops, lockInfo);
>>>>>> that initialises it ..
>>>>>>
>>>>>>
>>>>>> That is still before the dereference
>>>>>> Anyway, what was the reason for updating one function, but not the
>>>> other.
>>>>>> I don't mind the change, but the inconsistency looks odd.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>>> Did you actually compile this ? The variable is called "rasBase", not
>>>>>>>> "resBase".
>>>>>>> Yes, I compiled it, and I fixed the error, but that was another repo
>>>>>>> I use for the coverity checks.  Somehow it did not find its way into
>>>>>>> the webrev.
>>>>>>>
>>>>>>> I don't see where ops->Lock() initializes this field.
>>>>>>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
>>>>>>> to BufImg_GetRasInfo().  I can't look in our code scan results
>>>>>>> because the issue is gone after fixing it, that lists the path
>>>>>>> of execution that leads to the issue.
>>>>>>> If you are sure this is correct I will remove the initialization,
>>>>>>> else I will also put it into the other method.
>>>>>>>
>>>>>>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
>>>>>>> does what looks like the error case if it's NULL. Therefore NULL
>>>>>>> seemed a good initialization to me.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>       Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Phil Race [mailto:philip.race at oracle.com]
>>>>>>>> Sent: Mittwoch, 30. November 2016 20:59
>>>>>>>> To: Sergey Bylokhov<Sergey.Bylokhov at oracle.com>; Lindenmaier,
>>>> Goetz
>>>>>>>> <goetz.lindenmaier at sap.com>; Vincent Ryan
>>>> <vincent.x.ryan at oracle.com>
>>>>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>;
>>>> security-
>>>>>>>> dev at openjdk.java.net
>>>>>>>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix
>> minor
>>>>>> issues
>>>>>>>> in awt coding
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>>>       DataBufferNative.c
>>>>>>>>> Using uninitialized value lockInfo.rasBase when calling
>>>>>> DBN_GetPixelPointer.
>>>>>>>>        75     lockInfo.resBase = NULL;
>>>>>>>>
>>>>>>>> Did you actually compile this ? The variable is called "rasBase", not
>>>>>>>> "resBase".
>>>>>>>>
>>>>>>>> And strictly there is no problem since inside  DBN_GetPixelPointer
>>>>>>>> the code calls ops->Lock which should initialise this.
>>>>>>>> A "rasBase" of 0 isn't really any better than a random one ..
>>>>>>>>
>>>>>>>> Also I don't see why there's a problem here and not in
>>>>>>>> the function immediately following since it is the exact same case.
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
>>>>>>>>> cc 2d-dev.
>>>>>>>>>
>>>>>>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
>>>>>>>>>> Hi Vincent,
>>>>>>>>>>
>>>>>>>>>> thanks for the quit review!
>>>>>>>>>> Good catch that I lost the change to p11_mutex.c ... I had to
>> change
>>>>>>>>>> it and it fell out of my patches.
>>>>>>>>>> I edited the Last Modified Date, and also updated the copyright
>>>>>>>>>> messages.
>>>>>>>>>> New webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>       Goetz.
>>>>>>>>>>
>>>>>>>>>> (Am I correct that your openJdk name is Vinnie?)
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
>>>>>>>>>>> Sent: Mittwoch, 30. November 2016 14:53
>>>>>>>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>
>>>>>>>>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net
>>>>>>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
>>>>>>>>>>>
>>>>>>>>>>> Hello Goetz,
>>>>>>>>>>>
>>>>>>>>>>> Please modify the bug summary to reference ECC too.
>>>>>>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in
>> the
>>>>>>>>>>> 4 source
>>>>>>>>>>> code headers will need to be updated/added.
>>>>>>>>>>>
>>>>>>>>>>> BTW p11_mutex.c is listed below but appears to be missing from
>>>> the
>>>>>>>>>>> webrev.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
>>>>>>>>>>> <goetz.lindenmaier at sap.com
>>>> <mailto:goetz.lindenmaier at sap.com>  >
>>>>>>>> wrote:
>>>>>>>>>>>         Hi,
>>>>>>>>>>>
>>>>>>>>>>>         I?d like to propose a row of smaller fixes where code is noted
>>>>>>>>>>> down a
>>>>>>>>>>> bit questionable.
>>>>>>>>>>>         SAP?s quality process requires that we fix these in our internal
>>>>>>>>>>> delivery,
>>>>>>>>>>> and I
>>>>>>>>>>>         Would like to share my fixes with openJdk.  Some of these
>> fixes
>>>>>>>>>>> are of
>>>>>>>>>>> more
>>>>>>>>>>>         theoretical nature as how I understand the code paths never
>>>>>>>>>>> allow the
>>>>>>>>>>>         problematic situation, but fixing it nevertheless assures that
>>>>>>>>>>> nothing is
>>>>>>>>>>>         overseen if the code changes.  Most changes are in
>> libawt_xawt,
>>>>>>>>>>> some
>>>>>>>>>>>         are in libsunec.
>>>>>>>>>>>
>>>>>>>>>>>         I?d appreciate a review:
>>>>>>>>>>>         http://cr.openjdk.java.net/~goetz/wr16/8170525-
>>>> awt/webrev.01/
>>>>>>>>>>>         Changes in detail:
>>>>>>>>>>>
>>>>>>>>>>>         awt_InputMethod.c:
>>>>>>>>>>>
>>>>>>>>>>>         One might overrun the 100 byte fixed-size string
>>>>>>>>>>> statusWindow->status
>>>>>>>>>>> by copying text->string.multi_byte without checking the length.
>>>>>>>>>>>
>>>>>>>>>>>         gtk3_interface.c:
>>>>>>>>>>>
>>>>>>>>>>>         This less-than-zero comparison of an unsigned value is never
>>>> true.
>>>>>>>>>>>         Using uninitialized value color. Field color.alpha is
>>>>>>>>>>> uninitialized.
>>>>>>>>>>>         E.g. used at gtk3_interface.c:2287.
>>>>>>>>>>>
>>>>>>>>>>>         XToolkit.c
>>>>>>>>>>>
>>>>>>>>>>>         Using uninitialized value ret_timeout.
>>>>>>>>>>>         E.g. in XToolkit.c:6809.
>>>>>>>>>>>
>>>>>>>>>>>         XWindow.c
>>>>>>>>>>>
>>>>>>>>>>>         Argument is incompatible with corresponding format string
>>>>>>>>>>> conversion.
>>>>>>>>>>>
>>>>>>>>>>>         splashscreen_sys.c
>>>>>>>>>>>
>>>>>>>>>>>         Overflowed or truncated value (or a value computed from an
>>>>>>>>>>> overflowed or truncated value) (gdk_scale>  0) ? native_scale *
>>>>>>>>>>> (double)gdk_scale : native_scale used as return value.
>>>>>>>>>>>
>>>>>>>>>>>         ec.c
>>>>>>>>>>>
>>>>>>>>>>>         Using uninitialized value k.dp when calling mp_clear.
>>>>>>>>>>>
>>>>>>>>>>>         ecdecode.c
>>>>>>>>>>>
>>>>>>>>>>>         You might overrun the 291 byte fixed-size string genenc by
>>>> copying
>>>>>>>>>>> curveParams->geny without checking the length.
>>>>>>>>>>>         Added sanity check before doing the string concatenation.
>>>>>>>>>>>
>>>>>>>>>>>         ecl_mult.c
>>>>>>>>>>>
>>>>>>>>>>>         Using uninitialized value kt.flag when calling
>>>>>>>>>>> *group->point_mul. (The
>>>>>>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
>>>>>>>>>>>
>>>>>>>>>>>         mpi.c
>>>>>>>>>>>
>>>>>>>>>>>         Using uninitialized value s. Field s.flag is uninitialized when
>>>>>>>>>>> calling
>>>>>>>>>>> s_mp_exch.
>>>>>>>>>>>         Using uninitialized value tmp. Field tmp.flag is uninitialized
>> when
>>>>>>>>>>> calling s_mp_exch
>>>>>>>>>>>         Using uninitialized value t.dp when calling mp_clear.
>>>>>>>>>>>
>>>>>>>>>>>         p11_mutex.c
>>>>>>>>>>>
>>>>>>>>>>>         Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags
>> is
>>>>>>>>>>> uninitialized when calling memcpy.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         DataBufferNative.c
>>>>>>>>>>>
>>>>>>>>>>>         Using uninitialized value lockInfo.rasBase when calling
>>>>>>>>>>> BN_GetPixelPointer.
>>>>>>>>>>>
>>>>>>>>>>>         fontpath.c
>>>>>>>>>>>
>>>>>>>>>>>         You might overrun the 512 byte fixed-size string fontDirPath
>> by
>>>>>>>>>>> copying
>>>>>>>>>>> DirP->name[index] without checking the length.
>>>>>>>>>>>

From alexander.zvegintsev at oracle.com  Tue Dec  6 06:52:34 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 5 Dec 2016 22:52:34 -0800
Subject: <AWT Dev> [9] Review request for 8166683: On macOS (Mac OS X)
 getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"
In-Reply-To: <d8a28d6c-09b2-79ba-0dc7-c66bd12483f8@oracle.com>
References: <19fc27c1-7509-7a42-0602-244a53348e9d@oracle.com>
	<3ef28197-7315-4dc5-4918-d30fbe18c806@oracle.com>
	<c0a2834e-a6b1-94ce-c88d-ab06bc03b7ed@oracle.com>
	<11409341-3091-ff72-635d-98279979d26f@oracle.com>
	<d8a28d6c-09b2-79ba-0dc7-c66bd12483f8@oracle.com>
Message-ID: <7cddb2e9-eaa3-3c8b-dcc9-aae71dae005b@oracle.com>

Actually there is no need in this property, this behavior can be 
disabled for

other L&F by setting apple.laf.useScreenMenuBar property to false.

http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/03/

the fix is also reworked to remove mac specific stuff from shared code.

Thanks,
Alexander.

On 11/29/16 4:12 AM, Alexander Zvegintsev wrote:
> I don't find any modern jdk9 prefix convention for such property, so 
> I've named it "jdk.swing.disableForcedGlobalMenuBar"
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/02/
>
>
> Thanks,
> Alexander.
>
> On 11/28/16 9:05 PM, Sergey Bylokhov wrote:
>> Looks fine, but here is some of my thoughts:
>> Since we tries to provide some kind of public API, I suggest to 
>> double check the solution again. In fact we tried to provide a 
>> support of the global menu on osx for all our L&Fs.
>>  - Is it necessary to reference the Aqua from the shared code? in 
>> variables names and properties? Probably something like 
>> "globalMenuBar", etc? At least this will allow us to change 
>> implementation in any ways on other platforms w/o changing/adding the 
>> old/new properties.
>>
>> On 15.11.16 17:39, Alexander Zvegintsev wrote:
>>> Hi Sergey,
>>>
>>> I've not found casting issues, but I've found the issue when previous
>>> fix does not
>>>
>>> treat dynamically changed "apple.laf.useScreenMenuBar" property
>>> correctly. (e.g. ScreenMenuBarInputTwice test fails).
>>>
>>> So please see the updated changeset:
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/01/
>>>
>>> Thanks,
>>> Alexander.
>>>
>>> On 11/11/16 2:14 PM, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> Did you run the tests on non-Aqua l&f? I assume that we can have a
>>>> places in other l&f where we try to cast the MenuBarUI to some
>>>> specific UI delegate.
>>>>
>>>> On 09.11.16 16:58, Alexander Zvegintsev wrote:
>>>>> Hello,
>>>>>
>>>>> please review the fix
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/00/
>>>>>
>>>>> for the issue
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8166683
>>>>>
>>>>> This fix adds support for ScreenMenuBar for L&F's other than Aqua.
>>>>>
>>>>> With this fix it is enabled by default if apple.laf.useScreenMenuBar
>>>>> property is true.
>>>>>
>>>>> This behavior can be disabled by setting
>>>>> apple.laf.disableForcedScreenMenuBar property to true.
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From malenkov at gmail.com  Tue Dec  6 06:54:44 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Tue, 6 Dec 2016 09:54:44 +0300
Subject: <AWT Dev> [9] Review Request: 4419271 Provide support for
 scrolling-mechanisms of non-mouse input-devices
In-Reply-To: <1838634B-E343-4279-9652-A5D588FA236C@oracle.com>
References: <707681e3-0395-b04d-1ab1-b92767267776@oracle.com>
	<865c770d-0169-144a-4bab-5d7a897345ae@oracle.com>
	<CANTFZ2hG3BkfBGyccJ0FO-c45R_ZBGZjb7YqOpDKHmW+ArZkeA@mail.gmail.com>
	<1838634B-E343-4279-9652-A5D588FA236C@oracle.com>
Message-ID: <CANTFZ2hNpPoHoo8R1hvP=BUKeNk-gwhrNgU2hbeHSNy8XhC8QQ@mail.gmail.com>

I approve

On Tue, Dec 6, 2016 at 4:21 AM, Sergey Bylokhov
<sergey.bylokhov at oracle.com> wrote:
> Hi, Sergey.
> Please take a look to the updated version (the names are updated):
> http://cr.openjdk.java.net/~serb/4419271/webrev.03
>
>> 28 ????. 2016 ?., ? 7:01, Sergey Malenkov <malenkov at gmail.com> ???????(?):
>>
>> The fix looks good, but we realized that the direction is not always changed.
>> For example, Windows from VirtualBox on Mac.
>>
>> -    jint scrollLines = 3;
>> +    jint toScroll = 3;
>>
>> -    UINT platformLines;
>> +    UINT platformUnits;
>>
>> Also I prefer to use similar names for this variables as before.
>> For example, scrollUnits instead of toScroll
>>
>>
>>
>> On Thu, Nov 24, 2016 at 4:32 PM, Alexandr Scherbatiy
>> <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>> The fix looks good to me.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>
>>> On 11/23/2016 5:20 PM, Sergey Bylokhov wrote:
>>>>
>>>> Hello.
>>>>
>>>> Please review the fix for jdk9.
>>>>
>>>> Support of WM_MOUSEHWHEEL for Swing was added (AWT components were not
>>>> touched), which mostly the code symmetric to the WM_MOUSEWHEEL, except that
>>>> I changed the direction to align it in Swing and OS. It seems that this
>>>> functionality does not work on linux as well, at least I was not able to
>>>> enable it. Will file a separate bug for jdk on linux.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4419271
>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/4419271/webrev.02
>>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Sergey A. Malenkov
>



-- 
Best regards,
Sergey A. Malenkov

From volker.simonis at gmail.com  Tue Dec  6 09:59:26 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Dec 2016 10:59:26 +0100
Subject: <AWT Dev> Fwd: [PATCH]: few memory errors fixes
In-Reply-To: <CA+XhMqxwQp0OFHnty86BdYH_bj50zkt65aM1gN-BAeZ_pCQ=mA@mail.gmail.com>
References: <CA+XhMqxwQp0OFHnty86BdYH_bj50zkt65aM1gN-BAeZ_pCQ=mA@mail.gmail.com>
Message-ID: <CA+3eh11CVOHPJR-i8i5R6rEm8FCO+aX52e64zZNO-dK2HDzF_g@mail.gmail.com>

Hi David,

thanks for your contribution. Your fixes look reasonable.
I'm forwarding your mail to to core-libs-dev and awt-dev for reviewing.

Regards,
Volker


---------- Forwarded message ----------
From: David CARLIER <devnexen at gmail.com>
Date: Mon, Dec 5, 2016 at 10:10 PM
Subject: [PATCH]: few memory errors fixes
To: jdk9-dev at openjdk.java.net


Hi,

this is my first patch sent to the mailing list. One corrects the wrong
delete operator used and a potential memory leak.

Hope it is useful.

Kind regards.
-------------- next part --------------
diff --git a/src/java.base/share/native/libjimage/imageDecompressor.cpp b/src/java.base/share/native/libjimage/imageDecompressor.cpp
--- a/src/java.base/share/native/libjimage/imageDecompressor.cpp
+++ b/src/java.base/share/native/libjimage/imageDecompressor.cpp
@@ -181,7 +181,7 @@
         }
     } while (has_header);
     memcpy(uncompressed, decompressed_resource, (size_t) uncompressed_size);
-    delete decompressed_resource;
+    delete [] decompressed_resource;
 }
 
 // Zip decompressor
diff --git a/src/java.desktop/unix/native/common/awt/fontpath.c b/src/java.desktop/unix/native/common/awt/fontpath.c
--- a/src/java.desktop/unix/native/common/awt/fontpath.c
+++ b/src/java.desktop/unix/native/common/awt/fontpath.c
@@ -289,6 +289,7 @@
         onePath = SAFE_SIZE_ARRAY_ALLOC(malloc, strlen (fDirP->name[index]) + 2, sizeof( char ) );
         if (onePath == NULL) {
             free ( ( void *) appendDirList );
+            free ( ( void *) newFontPath );
             XFreeFontPath ( origFontPath );
             return;
         }

From goetz.lindenmaier at sap.com  Tue Dec  6 10:09:34 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 6 Dec 2016 10:09:34 +0000
Subject: <AWT Dev> Fwd: [PATCH]: few memory errors fixes
In-Reply-To: <CA+3eh11CVOHPJR-i8i5R6rEm8FCO+aX52e64zZNO-dK2HDzF_g@mail.gmail.com>
References: <CA+XhMqxwQp0OFHnty86BdYH_bj50zkt65aM1gN-BAeZ_pCQ=mA@mail.gmail.com>
	<CA+3eh11CVOHPJR-i8i5R6rEm8FCO+aX52e64zZNO-dK2HDzF_g@mail.gmail.com>
Message-ID: <9ac7ab7b4b4c46b1881eaa6315efe735@DEROTE13DE08.global.corp.sap>

Hi,

the fix to imageDecompressor.cpp is already reported in 
https://bugs.openjdk.java.net/browse/JDK-8170663
I'll send RFR for that today.
I'll add you to contributors.

Best regards,
  Goetz.

> -----Original Message-----
> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of
> Volker Simonis
> Sent: Dienstag, 6. Dezember 2016 10:59
> To: Java Core Libs <core-libs-dev at openjdk.java.net>; awt-
> dev at openjdk.java.net
> Subject: <AWT Dev> Fwd: [PATCH]: few memory errors fixes
> 
> Hi David,
> 
> thanks for your contribution. Your fixes look reasonable.
> I'm forwarding your mail to to core-libs-dev and awt-dev for reviewing.
> 
> Regards,
> Volker
> 
> 
> ---------- Forwarded message ----------
> From: David CARLIER <devnexen at gmail.com>
> Date: Mon, Dec 5, 2016 at 10:10 PM
> Subject: [PATCH]: few memory errors fixes
> To: jdk9-dev at openjdk.java.net
> 
> 
> Hi,
> 
> this is my first patch sent to the mailing list. One corrects the wrong
> delete operator used and a potential memory leak.
> 
> Hope it is useful.
> 
> Kind regards.

From sergey.bylokhov at oracle.com  Wed Dec  7 00:40:16 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Dec 2016 16:40:16 -0800
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
 dialog should be always on the top when multiple applets with
 APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <584157FA.20304@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
	<e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
	<584157FA.20304@oracle.com>
Message-ID: <62663002-FCD4-4C24-82FA-74501E0C0AC0@oracle.com>

This logic looks better by it is unclear why you increase the toolkit?s counter?
[AWTToolkit eventCountPlusPlus];
This counter should be increased in the native callbacks and should indicate that there are some activity on the toolkit thread. But it seems it is unnecessary in the new isBlocked() method?

> 2 ???. 2016 ?., ? 3:16, dmitry markov <dmitry.markov at oracle.com> ???????(?):
> 
> Hi Sergey,
> 
> According to the current implementation we disable a window only when we are going to show a modal dialog. However I agree it is not a good idea to use isEnabled flag for testing whether the window is blocked or not, since such logic is not clear and might be accidentally broken. So I have updated the fix; new webrev is located at http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/
> Summary of changes:
> - Added a new function isBlocked() to CPlatformWindow class
> - In AWTWindow.m use isBlocked() instead of isEnabled in the cases where we have to decide whether the ordering operation is required or not.
> 
> Thanks,
> Dmitry
> On 01/12/2016 03:29, Sergey Bylokhov wrote:
>> Hi, Dmitry.
>> Is it true that the window is disable only if blocked by some other window? Is it possible a situation when it can be disabled by application and in the same moment can have an enabled child which should be moved upfront?
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161206/a63875e0/attachment.html>

From prem.balakrishnan at oracle.com  Wed Dec  7 06:24:21 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Tue, 6 Dec 2016 22:24:21 -0800 (PST)
Subject: <AWT Dev> Review Request JDK:-8162959 [HiDPI] screenshot
 artifacts using AWT Robot
In-Reply-To: <85d3e709-727d-a948-bccd-3737867f974f@oracle.com>
References: <d9e5cffb-e2cb-41d8-8557-4aa994ae99c6@default>
	<1cbc0e01-8da3-9c44-498b-f2725a9ded2d@oracle.com>
	<3234fd3e-da5f-4ef9-9b25-7604464f01c7@default>
	<a4a5fd66-0000-a0dc-c387-d757384ba477@oracle.com>
	<07dc31bf-c52a-4c86-8cd9-b62f622d4338@default>
	<85d3e709-727d-a948-bccd-3737867f974f@oracle.com>
Message-ID: <b461ab16-af12-4ed3-91b7-392b3ffd66fa@default>

Hi Alexander,

 

Please review updated patch as per review comments.

http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.03/

 

Regards,

Prem

 

 

From: Alexandr Scherbatiy 
Sent: Monday, November 21, 2016 8:10 PM
To: Prem Balakrishnan; Sergey Bylokhov; awt-dev at openjdk.java.net; Phil Race
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 11/16/2016 8:46 AM, Prem Balakrishnan wrote:



Hi Alexander, 

 

Please review update patch as per review comments.

HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.02/

 

With this patch, Robot.createScreenCapture(Rectangle) method returns a scaled down image on the HiDPI display.


- The native part on Mac OS X and Linux should be updated as well.

- 416      * Returns BufferedImage for Non-HiDPI display and MultiResolutionImage 
  417      * for HiDPI display with two resolution variants.

There should be added an explanation what is the content of the first and the second resolution variant.

Thanks,
Alexandr.




 

Regards,

Prem

 

From: Alexandr Scherbatiy 
Sent: Thursday, November 03, 2016 4:05 PM
To: Prem Balakrishnan; Sergey Bylokhov; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 11/2/2016 1:57 PM, Prem Balakrishnan wrote:




Hi Alexander,

 

Please review updated patch.

HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.01/

 

Added a new public API "Image createHiDPIScreenCapture(Rectangle screenRect)".

Returns an ordinary screenshot(BufferedImage) if the UI scale is 1.

 

Returns MultiResolutionImage for HiDPI display with two resolution variants,

1.       Low Resolution/base image with user input width and height,  I have used interpolation algorithm for scaling , adapted from JavaFX Robot (http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc),

2.       High Resolution image with scaled width and height .

  - Please, check that the Robot.createScreenCapture(Rectangle) method returns a scaled down image on the HiDPI display
  - Probably existing Java methods can be used for an image scaling.
  For example, there is the Image.getScaledInstance(int width, int height, int hints) method.
  Or may be it is better just to create an image with required size and draw the high-resolution image into it using a specific scale and rendering hints.

  Thanks,
  Alexandr.





 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Thursday, October 13, 2016 3:21 PM
To: Prem Balakrishnan; Sergey Bylokhov; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 06/10/16 15:28, Prem Balakrishnan wrote:

Hi,

 

 

Please review fix for JDK 9, 

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8162959 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/ 

 

I have adapted the same fix as used for JavaFX Robot 

Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8162783"JDK-8162783.

Patch: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc

 

 

New Public API " BufferedImage createScreenCapture(Rectangle screenRect, boolean isHiDPI)" is added,
Which will have a parameter to specify if HiDPI.

  It is better to a add public method which returns MultiResolution image on HiDPI display and  consists of two resoltion variants
   - base image which has size requested by a user
   - high-resolution image which creates an original screen capture
  
  The proposed by your algorithm can be applied to the base image. 
  For more details see JDK-8020618 [macosx] java.awt.Robot makes blurry screen captures on Retina 

  Thanks,
  Alexandr.





 
Regards,
Prem
 

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161206/8149dc27/attachment-0001.html>

From goetz.lindenmaier at sap.com  Wed Dec  7 07:20:29 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 7 Dec 2016 07:20:29 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in
 awt coding
In-Reply-To: <58462E8A.6090508@oracle.com>
References: <d23f1be41f1347878bab8614ffc8fc65@DEROTE13DE08.global.corp.sap>
	<A332F3BD-069A-4061-9695-1378DF6895B4@oracle.com>
	<c3e7003e5045492c808c4c16b0d4300b@DEROTE13DE08.global.corp.sap>
	<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com>
	<0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com>
	<3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap>
	<65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com>
	<81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap>
	<bfe2745b-a684-9d10-9622-a7f97f7db321@oracle.com>
	<2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap>
	<23a39908-37a6-aa9a-f78f-8f60144cdc02@oracle.com>
	<96c15a8dff544fcdb9dd7f86af83523c@DEROTE13DE08.global.corp.sap>
	<58462E8A.6090508@oracle.com>
Message-ID: <5eeefc4e0a4140b7b9fd02ca0b2a44d4@DEROTE13DE08.global.corp.sap>

Hi Phil, 

does that mean I can push the change, or will this happen through jprt?

Best regards,
  Goetz.

> -----Original Message-----
> From: Philip Race [mailto:philip.race at oracle.com]
> Sent: Tuesday, December 06, 2016 4:21 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; awt-
> dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor
> issues in awt coding
> 
> I didn't eyeball what you changed but JPRT is now happy.
> The build passes on all platforms...
> 
> -phil.
> 
> On 12/5/16, 2:47 PM, Lindenmaier, Goetz wrote:
> > Hi Phil,
> >
> > sorry for that! I fixed it, there is an other occurrence, too.
> > I double checked all the casts, there was also a mp_flags<->  mp_sign
> wrong in mpi.c
> > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.05/
> > (Also rebased the change)
> >
> > Best regards,
> >    Goetz
> >
> >> -----Original Message-----
> >> From: Phil Race [mailto:philip.race at oracle.com]
> >> Sent: Monday, December 05, 2016 7:26 PM
> >> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>; Sergey Bylokhov
> >> <Sergey.Bylokhov at oracle.com>
> >> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>
> >> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix minor
> >> issues in awt coding
> >>
> >> I tried it .. and just as well I did. It fails in the crypto code on Mac.
> >>
> >> jdk/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c:261:12: error:
> >> expression which evaluates to zero treated as a null pointer constant of
> type
> >> 'mp_digit *' (aka 'unsigned long *') [-Werror,-Wnon-literal-null-conversion]
> >>       k.dp = (mp_digit)0;
> >>              ^~~~~~~~~~~
> >> 1 error generated.
> >>
> >> -phil.
> >>
> >>
> >>
> >> On 12/3/2016 9:53 AM, Lindenmaier, Goetz wrote:
> >>> Hi Phil,
> >>>
> >>> that would be great, unfortunately I don't have access to JPRT.
> >>>
> >>> Thanks,
> >>>     Goetz.
> >>>
> >>>> -----Original Message-----
> >>>> From: Phil Race [mailto:philip.race at oracle.com]
> >>>> Sent: Friday, December 02, 2016 8:46 PM
> >>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>; Sergey
> Bylokhov
> >>>> <Sergey.Bylokhov at oracle.com>
> >>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>
> >>>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix minor
> >>>> issues in awt coding
> >>>>
> >>>> I had no other comments, except that it would be good to be sure
> >>>> that this builds on all relevant platforms .. using the 'blessed' compilers.
> >>>> If you like I can submit a JPRT job for you based on this patch.
> >>>>
> >>>> -phil.
> >>>>
> >>>> On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote:
> >>>>> Hi Phil,
> >>>>>
> >>>>> I added the initialization to the other function.
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-
> dev/webrev.04/
> >>>>>
> >>>>> I missed that because Coverity didn't complain.
> >>>>> It's not a perfect tool, but it finds sufficient issues
> >>>>> to make it worthwhile.   Is the other awt code fine?
> >>>>>
> >>>>> Best regards,
> >>>>>      Goetz.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Phil Race [mailto:philip.race at oracle.com]
> >>>>>> Sent: Donnerstag, 1. Dezember 2016 22:31
> >>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>; Sergey
> >> Bylokhov
> >>>>>> <Sergey.Bylokhov at oracle.com>; Vincent Ryan
> >>>> <vincent.x.ryan at oracle.com>
> >>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>;
> >>>> security-
> >>>>>> dev at openjdk.java.net
> >>>>>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix
> minor
> >>>> issues
> >>>>>> in awt coding
> >>>>>>
> >>>>>> Sorry. it is
> >>>>>>         ops->GetRasInfo(env, ops, lockInfo);
> >>>>>> that initialises it ..
> >>>>>>
> >>>>>>
> >>>>>> That is still before the dereference
> >>>>>> Anyway, what was the reason for updating one function, but not the
> >>>> other.
> >>>>>> I don't mind the change, but the inconsistency looks odd.
> >>>>>>
> >>>>>> -phil.
> >>>>>>
> >>>>>> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi Phil,
> >>>>>>>
> >>>>>>>> Did you actually compile this ? The variable is called "rasBase", not
> >>>>>>>> "resBase".
> >>>>>>> Yes, I compiled it, and I fixed the error, but that was another repo
> >>>>>>> I use for the coverity checks.  Somehow it did not find its way into
> >>>>>>> the webrev.
> >>>>>>>
> >>>>>>> I don't see where ops->Lock() initializes this field.
> >>>>>>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves
> >>>>>>> to BufImg_GetRasInfo().  I can't look in our code scan results
> >>>>>>> because the issue is gone after fixing it, that lists the path
> >>>>>>> of execution that leads to the issue.
> >>>>>>> If you are sure this is correct I will remove the initialization,
> >>>>>>> else I will also put it into the other method.
> >>>>>>>
> >>>>>>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and
> >>>>>>> does what looks like the error case if it's NULL. Therefore NULL
> >>>>>>> seemed a good initialization to me.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>       Goetz.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Phil Race [mailto:philip.race at oracle.com]
> >>>>>>>> Sent: Mittwoch, 30. November 2016 20:59
> >>>>>>>> To: Sergey Bylokhov<Sergey.Bylokhov at oracle.com>; Lindenmaier,
> >>>> Goetz
> >>>>>>>> <goetz.lindenmaier at sap.com>; Vincent Ryan
> >>>> <vincent.x.ryan at oracle.com>
> >>>>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-
> dev at openjdk.java.net>;
> >>>> security-
> >>>>>>>> dev at openjdk.java.net
> >>>>>>>> Subject: Re: [OpenJDK 2D-Dev]<AWT Dev>  RFR(M): 8170525: Fix
> >> minor
> >>>>>> issues
> >>>>>>>> in awt coding
> >>>>>>>>
> >>>>>>>> Hi Goetz,
> >>>>>>>>
> >>>>>>>>>       DataBufferNative.c
> >>>>>>>>> Using uninitialized value lockInfo.rasBase when calling
> >>>>>> DBN_GetPixelPointer.
> >>>>>>>>        75     lockInfo.resBase = NULL;
> >>>>>>>>
> >>>>>>>> Did you actually compile this ? The variable is called "rasBase", not
> >>>>>>>> "resBase".
> >>>>>>>>
> >>>>>>>> And strictly there is no problem since inside  DBN_GetPixelPointer
> >>>>>>>> the code calls ops->Lock which should initialise this.
> >>>>>>>> A "rasBase" of 0 isn't really any better than a random one ..
> >>>>>>>>
> >>>>>>>> Also I don't see why there's a problem here and not in
> >>>>>>>> the function immediately following since it is the exact same case.
> >>>>>>>>
> >>>>>>>> -phil.
> >>>>>>>>
> >>>>>>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote:
> >>>>>>>>> cc 2d-dev.
> >>>>>>>>>
> >>>>>>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote:
> >>>>>>>>>> Hi Vincent,
> >>>>>>>>>>
> >>>>>>>>>> thanks for the quit review!
> >>>>>>>>>> Good catch that I lost the change to p11_mutex.c ... I had to
> >> change
> >>>>>>>>>> it and it fell out of my patches.
> >>>>>>>>>> I edited the Last Modified Date, and also updated the copyright
> >>>>>>>>>> messages.
> >>>>>>>>>> New webrev:
> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/
> >>>>>>>>>>
> >>>>>>>>>> Best regards,
> >>>>>>>>>>       Goetz.
> >>>>>>>>>>
> >>>>>>>>>> (Am I correct that your openJdk name is Vinnie?)
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com]
> >>>>>>>>>>> Sent: Mittwoch, 30. November 2016 14:53
> >>>>>>>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>
> >>>>>>>>>>> Cc: awt-dev at openjdk.java.net; security-
> dev at openjdk.java.net
> >>>>>>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding
> >>>>>>>>>>>
> >>>>>>>>>>> Hello Goetz,
> >>>>>>>>>>>
> >>>>>>>>>>> Please modify the bug summary to reference ECC too.
> >>>>>>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in
> >> the
> >>>>>>>>>>> 4 source
> >>>>>>>>>>> code headers will need to be updated/added.
> >>>>>>>>>>>
> >>>>>>>>>>> BTW p11_mutex.c is listed below but appears to be missing
> from
> >>>> the
> >>>>>>>>>>> webrev.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>         On 30 Nov 2016, at 13:12, Lindenmaier, Goetz
> >>>>>>>>>>> <goetz.lindenmaier at sap.com
> >>>> <mailto:goetz.lindenmaier at sap.com>  >
> >>>>>>>> wrote:
> >>>>>>>>>>>         Hi,
> >>>>>>>>>>>
> >>>>>>>>>>>         I?d like to propose a row of smaller fixes where code is
> noted
> >>>>>>>>>>> down a
> >>>>>>>>>>> bit questionable.
> >>>>>>>>>>>         SAP?s quality process requires that we fix these in our
> internal
> >>>>>>>>>>> delivery,
> >>>>>>>>>>> and I
> >>>>>>>>>>>         Would like to share my fixes with openJdk.  Some of these
> >> fixes
> >>>>>>>>>>> are of
> >>>>>>>>>>> more
> >>>>>>>>>>>         theoretical nature as how I understand the code paths
> never
> >>>>>>>>>>> allow the
> >>>>>>>>>>>         problematic situation, but fixing it nevertheless assures
> that
> >>>>>>>>>>> nothing is
> >>>>>>>>>>>         overseen if the code changes.  Most changes are in
> >> libawt_xawt,
> >>>>>>>>>>> some
> >>>>>>>>>>>         are in libsunec.
> >>>>>>>>>>>
> >>>>>>>>>>>         I?d appreciate a review:
> >>>>>>>>>>>         http://cr.openjdk.java.net/~goetz/wr16/8170525-
> >>>> awt/webrev.01/
> >>>>>>>>>>>         Changes in detail:
> >>>>>>>>>>>
> >>>>>>>>>>>         awt_InputMethod.c:
> >>>>>>>>>>>
> >>>>>>>>>>>         One might overrun the 100 byte fixed-size string
> >>>>>>>>>>> statusWindow->status
> >>>>>>>>>>> by copying text->string.multi_byte without checking the length.
> >>>>>>>>>>>
> >>>>>>>>>>>         gtk3_interface.c:
> >>>>>>>>>>>
> >>>>>>>>>>>         This less-than-zero comparison of an unsigned value is
> never
> >>>> true.
> >>>>>>>>>>>         Using uninitialized value color. Field color.alpha is
> >>>>>>>>>>> uninitialized.
> >>>>>>>>>>>         E.g. used at gtk3_interface.c:2287.
> >>>>>>>>>>>
> >>>>>>>>>>>         XToolkit.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Using uninitialized value ret_timeout.
> >>>>>>>>>>>         E.g. in XToolkit.c:6809.
> >>>>>>>>>>>
> >>>>>>>>>>>         XWindow.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Argument is incompatible with corresponding format
> string
> >>>>>>>>>>> conversion.
> >>>>>>>>>>>
> >>>>>>>>>>>         splashscreen_sys.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Overflowed or truncated value (or a value computed from
> an
> >>>>>>>>>>> overflowed or truncated value) (gdk_scale>  0) ? native_scale *
> >>>>>>>>>>> (double)gdk_scale : native_scale used as return value.
> >>>>>>>>>>>
> >>>>>>>>>>>         ec.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Using uninitialized value k.dp when calling mp_clear.
> >>>>>>>>>>>
> >>>>>>>>>>>         ecdecode.c
> >>>>>>>>>>>
> >>>>>>>>>>>         You might overrun the 291 byte fixed-size string genenc by
> >>>> copying
> >>>>>>>>>>> curveParams->geny without checking the length.
> >>>>>>>>>>>         Added sanity check before doing the string concatenation.
> >>>>>>>>>>>
> >>>>>>>>>>>         ecl_mult.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Using uninitialized value kt.flag when calling
> >>>>>>>>>>> *group->point_mul. (The
> >>>>>>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.)
> >>>>>>>>>>>
> >>>>>>>>>>>         mpi.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Using uninitialized value s. Field s.flag is uninitialized when
> >>>>>>>>>>> calling
> >>>>>>>>>>> s_mp_exch.
> >>>>>>>>>>>         Using uninitialized value tmp. Field tmp.flag is uninitialized
> >> when
> >>>>>>>>>>> calling s_mp_exch
> >>>>>>>>>>>         Using uninitialized value t.dp when calling mp_clear.
> >>>>>>>>>>>
> >>>>>>>>>>>         p11_mutex.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Using uninitialized value *ckpInitArgs. Field ckpInitArgs-
> >flags
> >> is
> >>>>>>>>>>> uninitialized when calling memcpy.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>         DataBufferNative.c
> >>>>>>>>>>>
> >>>>>>>>>>>         Using uninitialized value lockInfo.rasBase when calling
> >>>>>>>>>>> BN_GetPixelPointer.
> >>>>>>>>>>>
> >>>>>>>>>>>         fontpath.c
> >>>>>>>>>>>
> >>>>>>>>>>>         You might overrun the 512 byte fixed-size string
> fontDirPath
> >> by
> >>>>>>>>>>> copying
> >>>>>>>>>>> DirP->name[index] without checking the length.
> >>>>>>>>>>>

From dmitry.markov at oracle.com  Wed Dec  7 10:24:34 2016
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 7 Dec 2016 13:24:34 +0300
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
	dialog should be always on the top when multiple applets with
	APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <62663002-FCD4-4C24-82FA-74501E0C0AC0@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
	<e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
	<584157FA.20304@oracle.com>
	<62663002-FCD4-4C24-82FA-74501E0C0AC0@oracle.com>
Message-ID: <A996000D-791E-4662-B617-68E508AEE5C2@oracle.com>

Hi Sergey,

I agree, it is not necessary to increase the toolkit counter here. It is a copy-paste error. I am sorry about that. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8165428/webrev.02/

Thanks,
Dmitry 
> On 07 Dec 2016, at 03:40, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> This logic looks better by it is unclear why you increase the toolkit?s counter?
> [AWTToolkit eventCountPlusPlus];
> This counter should be increased in the native callbacks and should indicate that there are some activity on the toolkit thread. But it seems it is unnecessary in the new isBlocked() method?
> 
>> 2 ???. 2016 ?., ? 3:16, dmitry markov <dmitry.markov at oracle.com <mailto:dmitry.markov at oracle.com>> ???????(?):
>> 
>> Hi Sergey,
>> 
>> According to the current implementation we disable a window only when we are going to show a modal dialog. However I agree it is not a good idea to use isEnabled flag for testing whether the window is blocked or not, since such logic is not clear and might be accidentally broken. So I have updated the fix; new webrev is located at http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/ <http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/>
>> Summary of changes:
>> - Added a new function isBlocked() to CPlatformWindow class
>> - In AWTWindow.m use isBlocked() instead of isEnabled in the cases where we have to decide whether the ordering operation is required or not.
>> 
>> Thanks,
>> Dmitry
>> On 01/12/2016 03:29, Sergey Bylokhov wrote:
>>> Hi, Dmitry.
>>> Is it true that the window is disable only if blocked by some other window? Is it possible a situation when it can be disabled by application and in the same moment can have an enabled child which should be moved upfront?
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161207/6336d0d0/attachment.html>

From sergey.bylokhov at oracle.com  Wed Dec  7 16:25:05 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Dec 2016 08:25:05 -0800
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
 dialog should be always on the top when multiple applets with
 APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <A996000D-791E-4662-B617-68E508AEE5C2@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
	<e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
	<584157FA.20304@oracle.com>
	<62663002-FCD4-4C24-82FA-74501E0C0AC0@oracle.com>
	<A996000D-791E-4662-B617-68E508AEE5C2@oracle.com>
Message-ID: <A61DA443-75FA-4AFF-8AA6-9F0377603567@oracle.com>

Looks fine.

> 7 ???. 2016 ?., ? 2:24, Dmitry Markov <Dmitry.Markov at oracle.com> ???????(?):
> 
> Hi Sergey,
> 
> I agree, it is not necessary to increase the toolkit counter here. It is a copy-paste error. I am sorry about that. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8165428/webrev.02/ <http://cr.openjdk.java.net/~dmarkov/8165428/webrev.02/>
> 
> Thanks,
> Dmitry 
>> On 07 Dec 2016, at 03:40, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> This logic looks better by it is unclear why you increase the toolkit?s counter?
>> [AWTToolkit eventCountPlusPlus];
>> This counter should be increased in the native callbacks and should indicate that there are some activity on the toolkit thread. But it seems it is unnecessary in the new isBlocked() method?
>> 
>>> 2 ???. 2016 ?., ? 3:16, dmitry markov <dmitry.markov at oracle.com <mailto:dmitry.markov at oracle.com>> ???????(?):
>>> 
>>> Hi Sergey,
>>> 
>>> According to the current implementation we disable a window only when we are going to show a modal dialog. However I agree it is not a good idea to use isEnabled flag for testing whether the window is blocked or not, since such logic is not clear and might be accidentally broken. So I have updated the fix; new webrev is located at http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/ <http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/>
>>> Summary of changes:
>>> - Added a new function isBlocked() to CPlatformWindow class
>>> - In AWTWindow.m use isBlocked() instead of isEnabled in the cases where we have to decide whether the ordering operation is required or not.
>>> 
>>> Thanks,
>>> Dmitry
>>> On 01/12/2016 03:29, Sergey Bylokhov wrote:
>>>> Hi, Dmitry.
>>>> Is it true that the window is disable only if blocked by some other window? Is it possible a situation when it can be disabled by application and in the same moment can have an enabled child which should be moved upfront?
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161207/63db17a3/attachment-0001.html>

From dmitry.markov at oracle.com  Wed Dec  7 18:01:51 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 07 Dec 2016 21:01:51 +0300
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
 dialog should be always on the top when multiple applets with
 APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <A61DA443-75FA-4AFF-8AA6-9F0377603567@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
	<e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
	<584157FA.20304@oracle.com>
	<62663002-FCD4-4C24-82FA-74501E0C0AC0@oracle.com>
	<A996000D-791E-4662-B617-68E508AEE5C2@oracle.com>
	<A61DA443-75FA-4AFF-8AA6-9F0377603567@oracle.com>
Message-ID: <58484E8F.1000604@oracle.com>

Thank you very much, Sergey!
Looking for the second +1 from someone else.

Thanks,
Dmitry
On 07/12/2016 19:25, Sergey Bylokhov wrote:
> Looks fine.
>
>> 7 ???. 2016 ?., ? 2:24, Dmitry Markov <Dmitry.Markov at oracle.com 
>> <mailto:Dmitry.Markov at oracle.com>> ???????(?):
>>
>> Hi Sergey,
>>
>> I agree, it is not necessary to increase the toolkit counter here. It 
>> is a copy-paste error. I am sorry about that. Please find the updated 
>> webrev here: http://cr.openjdk.java.net/~dmarkov/8165428/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Edmarkov/8165428/webrev.02/>
>>
>> Thanks,
>> Dmitry
>>> On 07 Dec 2016, at 03:40, Sergey Bylokhov 
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> This logic looks better by it is unclear why you increase the 
>>> toolkit?s counter?
>>> [AWTToolkit eventCountPlusPlus];
>>> This counter should be increased in the native callbacks and should 
>>> indicate that there are some activity on the toolkit thread. But it 
>>> seems it is unnecessary in the new isBlocked() method?
>>>
>>>> 2 ???. 2016 ?., ? 3:16, dmitry markov <dmitry.markov at oracle.com 
>>>> <mailto:dmitry.markov at oracle.com>> ???????(?):
>>>>
>>>> Hi Sergey,
>>>>
>>>> According to the current implementation we disable a window only 
>>>> when we are going to show a modal dialog. However I agree it is not 
>>>> a good idea to use isEnabled flag for testing whether the window is 
>>>> blocked or not, since such logic is not clear and might be 
>>>> accidentally broken. So I have updated the fix; new webrev is 
>>>> located at http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/ 
>>>> <http://cr.openjdk.java.net/%7Edmarkov/8165428/webrev.01/>
>>>> Summary of changes:
>>>> - Added a new function isBlocked() to CPlatformWindow class
>>>> - In AWTWindow.m use isBlocked() instead of isEnabled in the cases 
>>>> where we have to decide whether the ordering operation is required 
>>>> or not.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>> On 01/12/2016 03:29, Sergey Bylokhov wrote:
>>>>> Hi, Dmitry.
>>>>> Is it true that the window is disable only if blocked by some 
>>>>> other window? Is it possible a situation when it can be disabled 
>>>>> by application and in the same moment can have an enabled child 
>>>>> which should be moved upfront?
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161207/cc4bbbf6/attachment.html>

From sergey.bylokhov at oracle.com  Wed Dec  7 20:51:53 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Dec 2016 12:51:53 -0800
Subject: <AWT Dev> [9] Review request for 8166683: On macOS (Mac OS X)
 getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"
In-Reply-To: <7cddb2e9-eaa3-3c8b-dcc9-aae71dae005b@oracle.com>
References: <19fc27c1-7509-7a42-0602-244a53348e9d@oracle.com>
	<3ef28197-7315-4dc5-4918-d30fbe18c806@oracle.com>
	<c0a2834e-a6b1-94ce-c88d-ab06bc03b7ed@oracle.com>
	<11409341-3091-ff72-635d-98279979d26f@oracle.com>
	<d8a28d6c-09b2-79ba-0dc7-c66bd12483f8@oracle.com>
	<7cddb2e9-eaa3-3c8b-dcc9-aae71dae005b@oracle.com>
Message-ID: <05C05B78-CB21-4CA3-B20B-6497978BC664@oracle.com>

Looks fine.

> 5 ???. 2016 ?., ? 22:52, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> ???????(?):
> 
> Actually there is no need in this property, this behavior can be disabled for
> 
> other L&F by setting apple.laf.useScreenMenuBar property to false.
> 
> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/03/
> 
> the fix is also reworked to remove mac specific stuff from shared code.
> 
> Thanks,
> Alexander.
> 
> On 11/29/16 4:12 AM, Alexander Zvegintsev wrote:
>> I don't find any modern jdk9 prefix convention for such property, so I've named it "jdk.swing.disableForcedGlobalMenuBar"
>> 
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/02/
>> 
>> 
>> Thanks,
>> Alexander.
>> 
>> On 11/28/16 9:05 PM, Sergey Bylokhov wrote:
>>> Looks fine, but here is some of my thoughts:
>>> Since we tries to provide some kind of public API, I suggest to double check the solution again. In fact we tried to provide a support of the global menu on osx for all our L&Fs.
>>> - Is it necessary to reference the Aqua from the shared code? in variables names and properties? Probably something like "globalMenuBar", etc? At least this will allow us to change implementation in any ways on other platforms w/o changing/adding the old/new properties.
>>> 
>>> On 15.11.16 17:39, Alexander Zvegintsev wrote:
>>>> Hi Sergey,
>>>> 
>>>> I've not found casting issues, but I've found the issue when previous
>>>> fix does not
>>>> 
>>>> treat dynamically changed "apple.laf.useScreenMenuBar" property
>>>> correctly. (e.g. ScreenMenuBarInputTwice test fails).
>>>> 
>>>> So please see the updated changeset:
>>>> 
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/01/
>>>> 
>>>> Thanks,
>>>> Alexander.
>>>> 
>>>> On 11/11/16 2:14 PM, Sergey Bylokhov wrote:
>>>>> Hi, Alexander.
>>>>> Did you run the tests on non-Aqua l&f? I assume that we can have a
>>>>> places in other l&f where we try to cast the MenuBarUI to some
>>>>> specific UI delegate.
>>>>> 
>>>>> On 09.11.16 16:58, Alexander Zvegintsev wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> please review the fix
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/00/
>>>>>> 
>>>>>> for the issue
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166683
>>>>>> 
>>>>>> This fix adds support for ScreenMenuBar for L&F's other than Aqua.
>>>>>> 
>>>>>> With this fix it is enabled by default if apple.laf.useScreenMenuBar
>>>>>> property is true.
>>>>>> 
>>>>>> This behavior can be disabled by setting
>>>>>> apple.laf.disableForcedScreenMenuBar property to true.
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 


From philip.race at oracle.com  Wed Dec  7 23:37:37 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 07 Dec 2016 15:37:37 -0800
Subject: <AWT Dev> [9] Review request for 8166683: On macOS (Mac OS X)
 getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"
In-Reply-To: <05C05B78-CB21-4CA3-B20B-6497978BC664@oracle.com>
References: <19fc27c1-7509-7a42-0602-244a53348e9d@oracle.com>
	<3ef28197-7315-4dc5-4918-d30fbe18c806@oracle.com>
	<c0a2834e-a6b1-94ce-c88d-ab06bc03b7ed@oracle.com>
	<11409341-3091-ff72-635d-98279979d26f@oracle.com>
	<d8a28d6c-09b2-79ba-0dc7-c66bd12483f8@oracle.com>
	<7cddb2e9-eaa3-3c8b-dcc9-aae71dae005b@oracle.com>
	<05C05B78-CB21-4CA3-B20B-6497978BC664@oracle.com>
Message-ID: <58489D41.2060802@oracle.com>

+1

-phil.

On 12/7/16, 12:51 PM, Sergey Bylokhov wrote:
> Looks fine.
>
>> 5 ???. 2016 ?., ? 22:52, Alexander Zvegintsev<alexander.zvegintsev at oracle.com>  ???????(?):
>>
>> Actually there is no need in this property, this behavior can be disabled for
>>
>> other L&F by setting apple.laf.useScreenMenuBar property to false.
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/03/
>>
>> the fix is also reworked to remove mac specific stuff from shared code.
>>
>> Thanks,
>> Alexander.
>>
>> On 11/29/16 4:12 AM, Alexander Zvegintsev wrote:
>>> I don't find any modern jdk9 prefix convention for such property, so I've named it "jdk.swing.disableForcedGlobalMenuBar"
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/02/
>>>
>>>
>>> Thanks,
>>> Alexander.
>>>
>>> On 11/28/16 9:05 PM, Sergey Bylokhov wrote:
>>>> Looks fine, but here is some of my thoughts:
>>>> Since we tries to provide some kind of public API, I suggest to double check the solution again. In fact we tried to provide a support of the global menu on osx for all our L&Fs.
>>>> - Is it necessary to reference the Aqua from the shared code? in variables names and properties? Probably something like "globalMenuBar", etc? At least this will allow us to change implementation in any ways on other platforms w/o changing/adding the old/new properties.
>>>>
>>>> On 15.11.16 17:39, Alexander Zvegintsev wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> I've not found casting issues, but I've found the issue when previous
>>>>> fix does not
>>>>>
>>>>> treat dynamically changed "apple.laf.useScreenMenuBar" property
>>>>> correctly. (e.g. ScreenMenuBarInputTwice test fails).
>>>>>
>>>>> So please see the updated changeset:
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/01/
>>>>>
>>>>> Thanks,
>>>>> Alexander.
>>>>>
>>>>> On 11/11/16 2:14 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Alexander.
>>>>>> Did you run the tests on non-Aqua l&f? I assume that we can have a
>>>>>> places in other l&f where we try to cast the MenuBarUI to some
>>>>>> specific UI delegate.
>>>>>>
>>>>>> On 09.11.16 16:58, Alexander Zvegintsev wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> please review the fix
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/00/
>>>>>>>
>>>>>>> for the issue
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166683
>>>>>>>
>>>>>>> This fix adds support for ScreenMenuBar for L&F's other than Aqua.
>>>>>>>
>>>>>>> With this fix it is enabled by default if apple.laf.useScreenMenuBar
>>>>>>> property is true.
>>>>>>>
>>>>>>> This behavior can be disabled by setting
>>>>>>> apple.laf.disableForcedScreenMenuBar property to true.
>>>>>>>
>>>>>>
>>>>

From maksim.khramov at oracle.com  Thu Dec  8 13:42:59 2016
From: maksim.khramov at oracle.com (Maksim Khramov)
Date: Thu, 8 Dec 2016 16:42:59 +0300
Subject: <AWT Dev> [9] Review request for 7147083: [TEST_BUG]
 DnDFileGroupDescriptor not applicable on Mac
Message-ID: <4394b54f-8f36-5bd9-f0f6-fa4af24dcbc5@oracle.com>

Hello,

please review this request...

Webrev: http://cr.openjdk.java.net/~yan/7147083/webrev.00/ 
<http://cr.openjdk.java.net/%7Eyan/7147083/webrev.00/>
Issue: https://bugs.openjdk.java.net/browse/JDK-7147083

Test bug. Applicable for windows platform only. Added @required tag

Thanks,
Maksim.

From sergey.bylokhov at oracle.com  Thu Dec  8 19:43:36 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Dec 2016 11:43:36 -0800
Subject: <AWT Dev> [9] Review request for 7147083: [TEST_BUG]
 DnDFileGroupDescriptor not applicable on Mac
In-Reply-To: <4394b54f-8f36-5bd9-f0f6-fa4af24dcbc5@oracle.com>
References: <4394b54f-8f36-5bd9-f0f6-fa4af24dcbc5@oracle.com>
Message-ID: <00E8328C-F45F-4EAD-9A81-6A046817AABF@oracle.com>

Looks fine.

> 8 ???. 2016 ?., ? 5:42, Maksim Khramov <maksim.khramov at oracle.com> ???????(?):
> 
> Hello,
> 
> please review this request...
> 
> Webrev: http://cr.openjdk.java.net/~yan/7147083/webrev.00/ <http://cr.openjdk.java.net/%7Eyan/7147083/webrev.00/>
> Issue: https://bugs.openjdk.java.net/browse/JDK-7147083
> 
> Test bug. Applicable for windows platform only. Added @required tag
> 
> Thanks,
> Maksim.


From semyon.sadetsky at oracle.com  Fri Dec  9 08:04:57 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 9 Dec 2016 11:04:57 +0300
Subject: <AWT Dev> [9] Review request for 7147083: [TEST_BUG]
 DnDFileGroupDescriptor not applicable on Mac
In-Reply-To: <4394b54f-8f36-5bd9-f0f6-fa4af24dcbc5@oracle.com>
References: <4394b54f-8f36-5bd9-f0f6-fa4af24dcbc5@oracle.com>
Message-ID: <e5a39982-9523-ca26-faca-a87e129d8097@oracle.com>

+1

Semyon


On 08.12.2016 16:42, Maksim Khramov wrote:
> Hello,
>
> please review this request...
>
> Webrev: http://cr.openjdk.java.net/~yan/7147083/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eyan/7147083/webrev.00/>
> Issue: https://bugs.openjdk.java.net/browse/JDK-7147083
>
> Test bug. Applicable for windows platform only. Added @required tag
>
> Thanks,
> Maksim.


From alexey.ivanov at oracle.com  Fri Dec  9 08:18:40 2016
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 9 Dec 2016 11:18:40 +0300
Subject: <AWT Dev> [9] Review request for 8165428: Security Warning
 dialog should be always on the top when multiple applets with
 APPLICATION_MODAL dialog launched in a browser
In-Reply-To: <58484E8F.1000604@oracle.com>
References: <01C948B8-3577-451E-9CCB-954BB6BE3755@oracle.com>
	<e3b6120b-2549-4f33-17a3-b6cf2e45da15@oracle.com>
	<584157FA.20304@oracle.com>
	<62663002-FCD4-4C24-82FA-74501E0C0AC0@oracle.com>
	<A996000D-791E-4662-B617-68E508AEE5C2@oracle.com>
	<A61DA443-75FA-4AFF-8AA6-9F0377603567@oracle.com>
	<58484E8F.1000604@oracle.com>
Message-ID: <c84597fd-bab0-c630-906e-81fa983c2093@oracle.com>

Looks fine to me too.


Regards,
Alexey

On 07.12.2016 21:01, dmitry markov wrote:
> Thank you very much, Sergey!
> Looking for the second +1 from someone else.
>
> Thanks,
> Dmitry
> On 07/12/2016 19:25, Sergey Bylokhov wrote:
>> Looks fine.
>>
>>> 7 ???. 2016 ?., ? 2:24, Dmitry Markov <Dmitry.Markov at oracle.com 
>>> <mailto:Dmitry.Markov at oracle.com>> ???????(?):
>>>
>>> Hi Sergey,
>>>
>>> I agree, it is not necessary to increase the toolkit counter here. 
>>> It is a copy-paste error. I am sorry about that. Please find the 
>>> updated webrev here: 
>>> http://cr.openjdk.java.net/~dmarkov/8165428/webrev.02/ 
>>> <http://cr.openjdk.java.net/%7Edmarkov/8165428/webrev.02/>
>>>
>>> Thanks,
>>> Dmitry
>>>> On 07 Dec 2016, at 03:40, Sergey Bylokhov 
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> This logic looks better by it is unclear why you increase the 
>>>> toolkit?s counter?
>>>> [AWTToolkit eventCountPlusPlus];
>>>> This counter should be increased in the native callbacks and should 
>>>> indicate that there are some activity on the toolkit thread. But it 
>>>> seems it is unnecessary in the new isBlocked() method?
>>>>
>>>>> 2 ???. 2016 ?., ? 3:16, dmitry markov <dmitry.markov at oracle.com 
>>>>> <mailto:dmitry.markov at oracle.com>> ???????(?):
>>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> According to the current implementation we disable a window only 
>>>>> when we are going to show a modal dialog. However I agree it is 
>>>>> not a good idea to use isEnabled flag for testing whether the 
>>>>> window is blocked or not, since such logic is not clear and might 
>>>>> be accidentally broken. So I have updated the fix; new webrev is 
>>>>> located at http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Edmarkov/8165428/webrev.01/>
>>>>> Summary of changes:
>>>>> - Added a new function isBlocked() to CPlatformWindow class
>>>>> - In AWTWindow.m use isBlocked() instead of isEnabled in the cases 
>>>>> where we have to decide whether the ordering operation is required 
>>>>> or not.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>> On 01/12/2016 03:29, Sergey Bylokhov wrote:
>>>>>> Hi, Dmitry.
>>>>>> Is it true that the window is disable only if blocked by some 
>>>>>> other window? Is it possible a situation when it can be disabled 
>>>>>> by application and in the same moment can have an enabled child 
>>>>>> which should be moved upfront?
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161209/3dd9d246/attachment.html>

From javalists at cbfiddle.com  Fri Dec  9 22:20:42 2016
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 9 Dec 2016 14:20:42 -0800
Subject: <AWT Dev> no mouse released event after window hidden on macOS
Message-ID: <77BBA72D-CAAA-4D23-8AD9-364D3078E623@cbfiddle.com>

I notice this comment in LWWindowPeer:

// TODO: currently, mouse released event goes to the same component
// that received corresponding mouse pressed event. For most cases,
// it's OK, however, we need to make sure that our behavior is consistent
// with 1.6 for cases where component in question have been
// hidden/removed in between of mouse pressed/released events.

and I have observed this behavior when clicking and releasing a mouse button over a tooltip (the tooltip is hidden and no mouse released event is dispatched).

By my reading of the spec <http://download.java.net/java/jdk9/docs/api/java/awt/event/MouseEvent.html>, this is a bug.

Should I file a bug report?

  Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161209/71de99fa/attachment.html>

From semyon.sadetsky at oracle.com  Mon Dec 12 09:45:51 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 12 Dec 2016 12:45:51 +0300
Subject: <AWT Dev> [9] Review Request: 8165769 Hang in the help menu item
In-Reply-To: <53e4ca52-05c7-ca59-8a7c-12ff72a1b0c7@oracle.com>
References: <65b6e222-38f2-8331-431c-731bc0a12bdf@oracle.com>
	<6b7504ba-bfd5-5861-b66b-4bd6a2170773@oracle.com>
	<ff4ed6a2-a85a-eb0d-d397-adef9140a982@oracle.com>
	<e84e117a-2e1a-fc9c-77fb-4b518fc5848e@oracle.com>
	<44919993-16d9-82ae-af3b-ebe5fabb8113@oracle.com>
	<4a25caea-8c27-879e-73e4-2330e0b338da@oracle.com>
	<9b22c3bf-b9dc-30b6-f799-439845577214@oracle.com>
	<a35ff051-9e5a-d144-b416-893d2673650e@oracle.com>
	<53e4ca52-05c7-ca59-8a7c-12ff72a1b0c7@oracle.com>
Message-ID: <5d960ec2-a6bf-10d2-2573-50515cb79b0a@oracle.com>

Hi Alexey,

On 11/28/2016 11:12 AM, Alexey Ivanov wrote:
> Hi Semyon, Sergey,
>
> On 17.11.2016 11:27, Semyon Sadetsky wrote:
>>
>>
>> On 16.11.2016 20:54, Sergey Bylokhov wrote:
>>> On 16.11.16 20:25, Semyon Sadetsky wrote:
>>>>> The example above produce the same result as if the thread B will 
>>>>> call
>>>>> dispatchEventImpl() early than addItemListener() was called by thread
>>>>> A. And this is correct behavior(the new events will be proceeded only
>>>>> when we set newEventsOnly to true).
>>>>> addItemListener is synchronized, because we need to synchronize 
>>>>> access
>>>>> to the list of listeners "itemListener" when we add/remove listener.
>>>> Then explain to me why to make all those fields volatile? Because the
>>>> cache for the changed fields is guaranteed to be flushed upon exit 
>>>> from
>>>> the synchronized block, so the changes will be visible to other 
>>>> threads
>>>> when the method returns.
>>>
>>> The statement above is incorrect, there is no "cache". I do not know 
>>> where you get "changed fields is guaranteed to be flushed upon exit 
>>> from the synchronized block". Also there is no guarantee that the 
>>> reader will see the latest version of the field if the reader will 
>>> use another mutex or will not use synchronization at all. In the fix 
>>> "volatile" will guarantee that the readers will see the latest 
>>> version which was set.
>> Flushing the cache is reality. By adding volatile to all Menu* fields 
>> you didn't make the methods effects predictable in case of they are 
>> called concurrently because they are not synchronized between each 
>> other. After this change it still may not be recommended to use menus 
>> from different threads arbitrarily.
>
> Semyon is right that the updated values will be written to memory upon 
> exit from synchronized block.
>
> And Sergey is right that the above statement does not guarantee the 
> updated value will be read from memory. That is getter called on 
> another thread could still see the previous value. For getter to read 
> the updated value, it also has to be synchronized (on the same object 
> monitor).
Actually, it requires the same object monitor to keep the synchronized 
contract in full. To reload the local cache any read memory barrier is 
enough to have, for example, synchronized block enter or a Lock object 
lock() call.
The dispatchEventImpl(AWTEvent e) calls Lock.lock() in the beginning. It 
is enough to reload the non-volatile newEventsOnly field.

>
> To avoid synchronized in getters, volatile could be used as it 
> guarantees the reader will always see the latest written value.
>
>> Or if I'm wrong and this change is a real improvement why you don't 
>> add volatile to all AWT classes' fields? The rest AWT classes are not 
>> better synchronized than the menu onces.
>
> Unfortunately, you're right other AWT classes are not well-suited for 
> multi-threaded environment?
And they will after the fix.
Anyway, it is poor practices to convert all exiting fields to volatile 
mechanically without any analysis of the issue. Such fix just adds 
unnecessary overhead.
By the way. I removed all added volatile modifiers and run the test 
attached to the fix. The test always passes. It looks like the issue is 
not connected with the fields visibility between threads.

--Semyon
>
>
> Regards,
> Alexey
>
>>>>>> Same for enableEvents(long eventsToEnable) method.
>>>> Also, the state field setter is synchronized by this object monitor
>>>> while the peer object which it should notify is protected by another
>>>> monitor and may be reset concurrently.
>>>>>
>>>>>>> But in some corner cases we change this value, so it cannot be 
>>>>>>> final.
>>>>>> What is that corner case? The comment clearly states that it is 
>>>>>> never
>>>>>> changed.
>>>>>
>>>>> We have a setter and we call it in applets, trayicon and in X11.
>>>> But TryIcon is not a MenuComponent. It seems the comment is correct.
>>>
>>> But we still have a setter which is called by other code. Also it 
>>> cannot be made final because it is updated during de-serialization.
>> And you still did not answer where it is really called. Probably the 
>> setter may be removed? At least please update the comment statement 
>> since in the change you assumes that the opposite is true.
>>
>> Why you left without synchronization the analogous field in the 
>> Component class? This field is really modified I can give you examples.
>>>
>>>>>> Also it seems Menu#isHelpMenu field is never used except for 
>>>>>> toString()
>>>>>> and may be removed.
>>>>>
>>>>> Why it can be removed since it is used in the toString()?
>>>> Because in this case it looks like cache anti-pattern and it should be
>>>> replaced with the real value. For which purpose the toString() may be
>>>> used? for debugging? But it seems one cannot guarantee that the 
>>>> cache is
>>>> updated in each moment of time in case of multi-threading.
>>>
>>> It is used to provide an information in the "string" that this menu 
>>> is a helpmenu. It is used in some tests as well. We also should take 
>>> care since this object is Serializable.
>>>
>>>>>
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>  - When the submenu is removed from Menu/MenuBar we do not 
>>>>>>>>> reset its
>>>>>>>>> parent field if the Menu/MenuBar have peer==null. So if later we
>>>>>>>>> tried
>>>>>>>>> to call MenuBar.setHelpMenu(submenu) we skip this submenu 
>>>>>>>>> because we
>>>>>>>>> think it was added already.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165769
>>>>>>>>> Webrev can be found at:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8165769/webrev.00
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


From alexandr.scherbatiy at oracle.com  Wed Dec 14 11:48:13 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 14 Dec 2016 15:48:13 +0400
Subject: <AWT Dev> Review Request JDK:-8162959 [HiDPI] screenshot
 artifacts using AWT Robot
In-Reply-To: <b461ab16-af12-4ed3-91b7-392b3ffd66fa@default>
References: <d9e5cffb-e2cb-41d8-8557-4aa994ae99c6@default>
	<1cbc0e01-8da3-9c44-498b-f2725a9ded2d@oracle.com>
	<3234fd3e-da5f-4ef9-9b25-7604464f01c7@default>
	<a4a5fd66-0000-a0dc-c387-d757384ba477@oracle.com>
	<07dc31bf-c52a-4c86-8cd9-b62f622d4338@default>
	<85d3e709-727d-a948-bccd-3737867f974f@oracle.com>
	<b461ab16-af12-4ed3-91b7-392b3ffd66fa@default>
Message-ID: <868228c8-441c-c73f-6a47-0c040e17f576@oracle.com>

On 07/12/16 10:24, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Please review updated patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.03/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.03/>
>
   I used a simple app [1] to create a screenshot of a frame on Mac OS X:
         Rectangle rect = frame.getBounds();
         rect.setLocation(frame.getLocationOnScreen());
         BufferedImage img = robot.createScreenCapture(rect);

   It takes only bottom right quarter of the frame [2].

   Is it possible to use some API that makes a screenshot and returns an 
NSImage on Mac OS X?
   In this case it would be possible to get a high resolution 
representation from the NSImage and return it in the same way as it is 
updated on Windows and Linux.

   [1] 
http://cr.openjdk.java.net/~alexsch/8162959/screenshot/RobotScreenshot.java
   [2] http://cr.openjdk.java.net/~alexsch/8162959/screenshot/screenshot.png

   Thanks,
   Alexandr.
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Monday, November 21, 2016 8:10 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; awt-dev at openjdk.java.net; 
> Phil Race
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot 
> artifacts using AWT Robot
>
> On 11/16/2016 8:46 AM, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Please review update patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.02/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.02/>
>
> With this patch, Robot.createScreenCapture(Rectangle) method returns a 
> scaled down image on the HiDPI display.
>
>
> - The native part on Mac OS X and Linux should be updated as well.
>
> - 416      * Returns BufferedImage for Non-HiDPI display and 
> MultiResolutionImage
>   417      * for HiDPI display with two resolution variants.
>
> There should be added an explanation what is the content of the first 
> and the second resolution variant.
>
> Thanks,
> Alexandr.
>
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Thursday, November 03, 2016 4:05 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; awt-dev at openjdk.java.net 
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot 
> artifacts using AWT Robot
>
> On 11/2/2016 1:57 PM, Prem Balakrishnan wrote:
>
>
> Hi Alexander,
>
> Please review updated patch.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.01/>
>
> Added a new public API ?*Image createHiDPIScreenCapture(Rectangle 
> screenRect)?.*
>
> Returns an ordinary screenshot(BufferedImage) if the UI scale is 1.
>
> Returns MultiResolutionImage for HiDPI display with two resolution 
> variants,
>
> 1.Low Resolution/base image with user input width and height,  I have 
> used interpolation algorithm for scaling , adapted from JavaFX Robot 
> (http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc),
>
> 2.High Resolution image with scaled width and height .
>
>   - Please, check that the Robot.createScreenCapture(Rectangle) method 
> returns a scaled down image on the HiDPI display
>   - Probably existing Java methods can be used for an image scaling.
>   For example, there is the Image.getScaledInstance(int width, int 
> height, int hints) method.
>   Or may be it is better just to create an image with required size 
> and draw the high-resolution image into it using a specific scale and 
> rendering hints.
>
>   Thanks,
>   Alexandr.
>
>
>
> Regards,
>
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Thursday, October 13, 2016 3:21 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; awt-dev at openjdk.java.net 
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot 
> artifacts using AWT Robot
>
> On 06/10/16 15:28, Prem Balakrishnan wrote:
>
>     Hi*,*
>
>     **
>
>     Please review fix for JDK 9,
>
>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-8162959
>
>     *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/
>     <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.00/>
>
>     I have adapted the same fix as used for JavaFX Robot
>
>     *Bug: *JDK-8162783 <https://bugs.openjdk.java.net/browse/JDK-8162783>.
>
>     *Patch: *http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc
>
>     New Public API ? BufferedImage createScreenCapture(Rectangle
>     screenRect, boolean isHiDPI)?is added,
>
>     Which will have a parameter to specify if HiDPI.
>
>   It is better to a add public method which returns MultiResolution 
> image on HiDPI display and  consists of two resoltion variants
>    - base image which has size requested by a user
>    - high-resolution image which creates an original screen capture
>
>   The proposed by your algorithm can be applied to the base image.
>   For more details see JDK-8020618 [macosx] java.awt.Robot makes 
> blurry screen captures on Retina
>
>   Thanks,
>   Alexandr.
>
>
>
>   
> Regards,
> Prem
>   
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161214/02487637/attachment.html>

From sergey.bylokhov at oracle.com  Wed Dec 14 18:19:19 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Dec 2016 21:19:19 +0300
Subject: <AWT Dev> no mouse released event after window hidden on macOS
In-Reply-To: <77BBA72D-CAAA-4D23-8AD9-364D3078E623@cbfiddle.com>
References: <77BBA72D-CAAA-4D23-8AD9-364D3078E623@cbfiddle.com>
Message-ID: <3D047C44-855C-4454-B3E5-C100B50420DF@oracle.com>

Hi, Alan.
> 
> By my reading of the spec <http://download.java.net/java/jdk9/docs/api/java/awt/event/MouseEvent.html>, this is a bug.
> 
> Should I file a bug report?

Yes, please create a new bug report. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161214/b62fd335/attachment-0001.html>

From sergey.bylokhov at oracle.com  Thu Dec 15 10:02:45 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Dec 2016 13:02:45 +0300
Subject: <AWT Dev> [9] fix for JDK-8134612
 :clipboard.getData(dataFlavor) can throw UnsupportedFlavorException for
 registered data flavor
In-Reply-To: <87d2de36-39ab-b64b-02cb-e5373e93d5b5@oracle.com>
References: <f48f37cb-d80f-4458-9ab6-5b5464ff4971@default>
	<09c47deb-0740-05d3-6a94-ad4711f66930@oracle.com>
	<9f0fce7d-8caa-4cf2-a806-b496376875e3@default>
	<87d2de36-39ab-b64b-02cb-e5373e93d5b5@oracle.com>
Message-ID: <7A3B2C3C-CC08-4780-94D9-521AC8EB8BAA@oracle.com>

+1

> 29 ????. 2016 ?., ? 13:53, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com> ???????(?):
> 
> 
> The fix looks good to me.
> 
> The 8133719 could be also added to the test @bug tag.
> 
> Thanks,
> Alexandr.
> 
> On 11/28/2016 3:20 PM, Ajit Ghaisas wrote:
>> Thanks Alex for the review comments.
>>  
>> As suggested, I have updated the test which results in the call to DataTransferer.constructFlavoredObject() method.
>> Here is the new webrev.
>> http://cr.openjdk.java.net/~aghaisas/8134612/webrev.01/ <http://cr.openjdk.java.net/%7Eaghaisas/8134612/webrev.01/>
>>  
>> Note:
>> 1.       If the test in this webrev is run ? it results in the java.lang.InternalError ? it is due to an open bug JDK-8133719. 
>> 2.       I have tested the fix on Windows and Mac by temporarily changing the code that results in java.lang.InternalError.
>> 3.       Even with change in step2, the test fails with UnsupportedFlavorException on Linux ? it will be addressed in JDK-8170390.
>>  
>> This test fix will help in reproducing JDK-8133719 consistently on Windows and Mac.
>>  
>> Regards,
>> Ajit
>>  
>> From: Alexandr Scherbatiy 
>> Sent: Wednesday, September 14, 2016 8:33 PM
>> To: Ajit Ghaisas; Yuri Nesterenko; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: [9] fix for JDK-8134612 :clipboard.getData(dataFlavor) can throw UnsupportedFlavorException for registered data flavor
>>  
>>  
>> On 9/14/2016 1:14 PM, Ajit Ghaisas wrote:
>> Hi,
>>  
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8134612 <https://bugs.openjdk.java.net/browse/JDK-8134612>
>>  
>> Issue :
>> In this test, exportToClipboard() does not export anything to the clipboard due to incorrect text passed to TransferHandler.
>> Obviously, when we do clipboard.getData() - it throws UnsupportedFlavorException. This is the root cause.
>> Also, when text is imported, the text String cannot be assigned to MyStringReader class.
>>  
>> Fix :
>> The test is corrected to use custom dataflavor containing String to export and import from clipboard.
>> Also, the test is enhanced to test a custom dataflavor of Color.
>> I have referred to :
>> https://docs.oracle.com/javase/tutorial/uiswing/dnd/dataflavor.html <https://docs.oracle.com/javase/tutorial/uiswing/dnd/dataflavor.html>
>>  
>> It passes consistently on Windows, Linux and Mac.
>>  
>> Webrev :
>> http://cr.openjdk.java.net/~aghaisas/8134612/webrev.00/ <http://cr.openjdk.java.net/%7Eaghaisas/8134612/webrev.00/>
>>  
>> Request you to review.
>>   - The test has been designed to check that the reflection in DataTransferer.constructFlavoredObject() method properly works with the modularization system.
>>   Could the test be updated  to call  the DataTransferer.constructFlavoredObject() method which creates an object using flavor.getRepresentationClass() constructor? 
>> 
>>  - I also resent the email to the awt-dev alias.
>> 
>>   Thanks,
>>   Alexandr.
>> 
>>  
>> Regards,
>> Ajit
>>  
>>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161215/8ebeb906/attachment.html>

From javalists at cbfiddle.com  Thu Dec 15 14:27:15 2016
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 15 Dec 2016 06:27:15 -0800
Subject: <AWT Dev> no mouse released event after window hidden on macOS
In-Reply-To: <3D047C44-855C-4454-B3E5-C100B50420DF@oracle.com>
References: <77BBA72D-CAAA-4D23-8AD9-364D3078E623@cbfiddle.com>
	<3D047C44-855C-4454-B3E5-C100B50420DF@oracle.com>
Message-ID: <01DC6E10-8E2E-4812-82CD-57586EE6A4C4@cbfiddle.com>

JDK-8171305 <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8171305>

> On Dec 14, 2016, at 10:19 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Alan.
>> 
>> By my reading of the spec <http://download.java.net/java/jdk9/docs/api/java/awt/event/MouseEvent.html>, this is a bug.
>> 
>> Should I file a bug report?
> 
> Yes, please create a new bug report. Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161215/02935852/attachment-0001.html>

From philip.race at oracle.com  Fri Dec 16 23:27:20 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Dec 2016 15:27:20 -0800
Subject: <AWT Dev> RFR: 8171363: [PIT] Four Windows-specific tests fail with
 InaccessibleObjectException when calling Field.setAccessible()
Message-ID: <070054c8-0c66-f6ae-ea54-1ab8a58d75cd@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8171363
Webrev: http://cr.openjdk.java.net/~prr/8171363/

this is mostly about jtreg syntax.

A few tests fail due to the updated module system spec.
jtreg needs to allow them to access package private fields.
":open" is added on the tests that do this and need runtime access to 
the non-exported package
":+open" is added on the tests also need compile-time access.

-phil.

From mandy.chung at oracle.com  Fri Dec 16 23:32:20 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 16 Dec 2016 15:32:20 -0800
Subject: <AWT Dev> RFR: 8171363: [PIT] Four Windows-specific tests fail
	with InaccessibleObjectException when calling Field.setAccessible()
In-Reply-To: <070054c8-0c66-f6ae-ea54-1ab8a58d75cd@oracle.com>
References: <070054c8-0c66-f6ae-ea54-1ab8a58d75cd@oracle.com>
Message-ID: <320C8F88-AA9C-4EE5-9C0A-9AC6D8DED9A8@oracle.com>


> On Dec 16, 2016, at 3:27 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171363
> Webrev: http://cr.openjdk.java.net/~prr/8171363/

+1

Mandy


From maksim.khramov at oracle.com  Mon Dec 19 15:47:15 2016
From: maksim.khramov at oracle.com (Maksim Khramov)
Date: Mon, 19 Dec 2016 18:47:15 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
Message-ID: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>

Hello,

please review this request...

Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ 
<http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/>
Issue: https://bugs.openjdk.java.net/browse/JDK-8154314

Test bug. Compilation of 
java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java still 
fails due removed method

Thanks,
Maksim.

From semyon.sadetsky at oracle.com  Mon Dec 19 17:13:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 19 Dec 2016 20:13:17 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
Message-ID: <a7896b81-3627-dc7a-ccb3-020ca6215b95@oracle.com>

+1

--Semyon


On 19.12.2016 18:47, Maksim Khramov wrote:
> Hello,
>
> please review this request...
>
> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314
>
> Test bug. Compilation of 
> java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java 
> still fails due removed method
>
> Thanks,
> Maksim.


From alexander.zvegintsev at oracle.com  Mon Dec 19 17:21:24 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 19 Dec 2016 20:21:24 +0300
Subject: <AWT Dev> [9] Review request for 8167652: Making a frame/dialog
 resizeble/unresizeble shifts its position on Unity.
In-Reply-To: <d862f852-68a2-94c9-49a9-6a4253570ed0@oracle.com>
References: <242ce147-4ff9-68c1-e5c7-278e1215fcda@oracle.com>
	<2113be8e-f17e-ef55-27f8-de3d9c525b93@oracle.com>
	<d862f852-68a2-94c9-49a9-6a4253570ed0@oracle.com>
Message-ID: <4fc3658b-369a-1172-3a20-f38c2af9bb26@oracle.com>

Looks good to me.

Thanks,
Alexander.

On 26/10/2016 16:06, Semyon Sadetsky wrote:
> Please review the updated fix: 
> http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.01/
>
> - unnecessary AWT locks are removed
>
> - client code calls are taken away from AWT lock blocks
>
> - some design improvements are made
>
> --Semyon
>
>
> On 10/19/2016 8:38 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> A few notes.
>>  - The awtLock is a lowlevel lock which should be used only when we 
>> access the xlib and some other native resource like opengl. We should 
>> not call the users code on it. In the fix the code in 
>> XDecoratedPeer.updateMinimumSize() will call the users code.
>>  - Some of the changed methods are called already under this lock, 
>> for example XDecoratedPeer.handlePropertyNotify(), and probably others.
>>
>> On 18.10.16 16:46, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8167652
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.00/
>>>
>>> In Linux, when a frame or dilalog is made resizable or non-resizable 
>>> the
>>> window decoration need to be updated. For that purpose window is
>>> unmapped and mapped again and WM changes the window decoration parent.
>>> The re-parenting may cause WM to send intermediate "artifact events"
>>> which change the window location on the screen, this WM behavior is
>>> undocumented. To avoid window move the window shift is compensated in
>>> XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts
>>> the window position in different way. In the proposed solution the
>>> window shift compensation is adjusted for Unity WM.
>>>
>>> Also in the fix all writes to the fields that store the current 
>>> state of
>>> window dimensions are protected with the AWT lock. This is necessary to
>>> avoid unexpected window move or resize when the window dimensions are
>>> changed from the user thread concurrently while the AWT toolkit thread
>>> handles WM sent notifications affecting the current window state, size,
>>> position, insets, etc.
>>>
>>> --Semyon
>>>
>>
>>
>


From sergey.bylokhov at oracle.com  Mon Dec 19 17:32:25 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Dec 2016 20:32:25 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
Message-ID: <4F63F1BF-2854-4229-BC92-AB231DD79E39@oracle.com>

Hi, Maksim.
It seems that this code was written when the ?getDefaultTransform()? returns an identity transform, this is why the MultiResolutionDragImageTest.getScaleFactor() uses an internal method of the SunGraphics2D. Since then the getDefaultTransform() was updated and can be used directly(like in your fix), but it looks like all other stuff in MultiResolutionDragImageTest.getScaleFactor() is not necessary and can be removed, because the Graphics which is passed to paint() method is not used anymore.

> 
> Hello,
> 
> please review this request...
> 
> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314
> 
> Test bug. Compilation of java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java still fails due removed method
> 
> Thanks,
> Maksim.


From sergey.bylokhov at oracle.com  Mon Dec 19 19:28:40 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Dec 2016 22:28:40 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <bc006214-ac0a-ca0e-7041-f586cf7cb910@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
	<f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
	<241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>
	<027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com>
	<bc006214-ac0a-ca0e-7041-f586cf7cb910@oracle.com>
Message-ID: <622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com>

Hello.
Please review an updated version of the fix.
 - The comments are updated.
Two additional public api are deprecated:
 - KeyEvent.getKeyModifiersText()
 - AWTEvent(Event event)

Note that I have to add @SuppressWarnings("deprecation?) in places where the old API is used, because the option which ignores this warning was removed from the makefile. We will need to fix all of them one by one in jdk10, I?ll file a CR for this.

> On 10/26/2016 6:43 PM, Sergey Bylokhov wrote:
>> On 25.10.16 18:46, Semyon Sadetsky wrote:
>>>> I wonder why he should decide that the old code can be "simply
>>>> replaced" by the new one? I suppose that at least he should read the
>>>> specification of the new extended API. There is no notion that this
>>>> api is replaced by the new one, there is a recommendation that the new
>>>> one should be used instead.
>>> After reading such recommendation it's hard to conclude that one "should
>>> read the specification of the new extended API". Even "@see" tag
>>> pointing to the extended API is not provided (I'm not even mentioning
>>> the warning that the extended API may be nonequivalent replacement is
>>> absent). I read this recommendation as it is: replace one constant with
>>> another, no side effects expected.
>> 
>> Good to know that you don't read the specification of the methods before using. So what is your proposal? Should I add a notion that these extendent constants contains different int values, and if the user depends from them in some way then he should not replace the old one to the new one? Or what @see reference should be added from some fields to another?
> The proposal is the same to notify user that he/she should not only replace the constant but start to use another API. It's up to you how to formulate this. If I did this in minimalistic way I would write:
> 
> @deprecated It is recommended that SHIFT_DOWN_MASK and {@link getModifiersEx()} be used instead.
>> 
>>>> 
>>>>>> We already have a notions that these "extended modifier constant"
>>>>>> should be used in the constructor of InputEvent and moreover in spec
>>>>>> of getModifiersEx() we have an additional examples how to use this
>>>>>> constants. This is why we will have a reference from old constans to
>>>>>> the new, and from getModifiers() to the getModifiersEx();

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161219/b02a7b26/attachment-0001.html>

From sergey.bylokhov at oracle.com  Mon Dec 19 19:29:21 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Dec 2016 22:29:21 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
	<f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
	<241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>
	<027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com>
	<bc006214-ac0a-ca0e-7041-f586cf7cb910@oracle.com>
	<622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com>
Message-ID: <0CC8F46C-C873-4617-B4E4-F2E9BA3F4360@oracle.com>


> 19 ???. 2016 ?., ? 22:28, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> ???????(?):
> 
> Hello.
> Please review an updated version of the fix.
>  - The comments are updated.
> Two additional public api are deprecated:
>  - KeyEvent.getKeyModifiersText()
>  - AWTEvent(Event event)
> 
> Note that I have to add @SuppressWarnings("deprecation?) in places where the old API is used, because the option which ignores this warning was removed from the makefile. We will need to fix all of them one by one in jdk10, I?ll file a CR for this.

Ouch the link is:
http://cr.openjdk.java.net/~serb/8143077/webrev.04/ <http://cr.openjdk.java.net/~serb/8143077/webrev.04/>

> 
>> On 10/26/2016 6:43 PM, Sergey Bylokhov wrote:
>>> On 25.10.16 18:46, Semyon Sadetsky wrote:
>>>>> I wonder why he should decide that the old code can be "simply
>>>>> replaced" by the new one? I suppose that at least he should read the
>>>>> specification of the new extended API. There is no notion that this
>>>>> api is replaced by the new one, there is a recommendation that the new
>>>>> one should be used instead.
>>>> After reading such recommendation it's hard to conclude that one "should
>>>> read the specification of the new extended API". Even "@see" tag
>>>> pointing to the extended API is not provided (I'm not even mentioning
>>>> the warning that the extended API may be nonequivalent replacement is
>>>> absent). I read this recommendation as it is: replace one constant with
>>>> another, no side effects expected.
>>> 
>>> Good to know that you don't read the specification of the methods before using. So what is your proposal? Should I add a notion that these extendent constants contains different int values, and if the user depends from them in some way then he should not replace the old one to the new one? Or what @see reference should be added from some fields to another?
>> The proposal is the same to notify user that he/she should not only replace the constant but start to use another API. It's up to you how to formulate this. If I did this in minimalistic way I would write:
>> 
>> @deprecated It is recommended that SHIFT_DOWN_MASK and {@link getModifiersEx()} be used instead.
>>> 
>>>>> 
>>>>>>> We already have a notions that these "extended modifier constant"
>>>>>>> should be used in the constructor of InputEvent and moreover in spec
>>>>>>> of getModifiersEx() we have an additional examples how to use this
>>>>>>> constants. This is why we will have a reference from old constans to
>>>>>>> the new, and from getModifiers() to the getModifiersEx();
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161219/a81e8684/attachment.html>

From sergey.bylokhov at oracle.com  Mon Dec 19 20:06:52 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Dec 2016 23:06:52 +0300
Subject: <AWT Dev> [9] Review request for 8167652: Making a frame/dialog
 resizeble/unresizeble shifts its position on Unity.
In-Reply-To: <4fc3658b-369a-1172-3a20-f38c2af9bb26@oracle.com>
References: <242ce147-4ff9-68c1-e5c7-278e1215fcda@oracle.com>
	<2113be8e-f17e-ef55-27f8-de3d9c525b93@oracle.com>
	<d862f852-68a2-94c9-49a9-6a4253570ed0@oracle.com>
	<4fc3658b-369a-1172-3a20-f38c2af9bb26@oracle.com>
Message-ID: <CC9F12B1-6AF3-4C89-BCEF-C61C74D3295A@oracle.com>

+1

> 
> Looks good to me.
> 
> Thanks,
> Alexander.
> 
> On 26/10/2016 16:06, Semyon Sadetsky wrote:
>> Please review the updated fix: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.01/
>> 
>> - unnecessary AWT locks are removed
>> 
>> - client code calls are taken away from AWT lock blocks
>> 
>> - some design improvements are made
>> 
>> --Semyon
>> 
>> 
>> On 10/19/2016 8:38 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> A few notes.
>>> - The awtLock is a lowlevel lock which should be used only when we access the xlib and some other native resource like opengl. We should not call the users code on it. In the fix the code in XDecoratedPeer.updateMinimumSize() will call the users code.
>>> - Some of the changed methods are called already under this lock, for example XDecoratedPeer.handlePropertyNotify(), and probably others.
>>> 
>>> On 18.10.16 16:46, Semyon Sadetsky wrote:
>>>> Hello,
>>>> 
>>>> Please review fix for JDK9:
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8167652
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.00/
>>>> 
>>>> In Linux, when a frame or dilalog is made resizable or non-resizable the
>>>> window decoration need to be updated. For that purpose window is
>>>> unmapped and mapped again and WM changes the window decoration parent.
>>>> The re-parenting may cause WM to send intermediate "artifact events"
>>>> which change the window location on the screen, this WM behavior is
>>>> undocumented. To avoid window move the window shift is compensated in
>>>> XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts
>>>> the window position in different way. In the proposed solution the
>>>> window shift compensation is adjusted for Unity WM.
>>>> 
>>>> Also in the fix all writes to the fields that store the current state of
>>>> window dimensions are protected with the AWT lock. This is necessary to
>>>> avoid unexpected window move or resize when the window dimensions are
>>>> changed from the user thread concurrently while the AWT toolkit thread
>>>> handles WM sent notifications affecting the current window state, size,
>>>> position, insets, etc.
>>>> 
>>>> --Semyon
>>>> 
>>> 
>>> 
>> 
> 


From david.holmes at oracle.com  Tue Dec 20 03:35:34 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Dec 2016 13:35:34 +1000
Subject: <AWT Dev> Building openjdk8 on windows 7,
	tests fail for i18n problems
In-Reply-To: <alpine.DEB.2.20.15.1612200300520.16331@kropotkin>
References: <43c8b463ac8e6f601f10ae6c100edd8f@pek00.hostsharing.net>
	<alpine.DEB.2.20.15.1612182143460.4722@kropotkin>
	<CANiY96a8SStM_o_eHs_uCABKcPoD3TGwws-=Hhq-Fia9RakanA@mail.gmail.com>
	<alpine.DEB.2.20.15.1612191244240.16331@kropotkin>
	<alpine.DEB.2.20.15.1612191355090.16331@kropotkin>
	<5cf91ec2-d39c-57fa-5a09-6891fd76df0f@oracle.com>
	<alpine.DEB.2.20.15.1612191602320.16331@kropotkin>
	<alpine.DEB.2.20.15.1612191728080.16331@kropotkin>
	<alpine.DEB.2.20.15.1612192236470.16331@kropotkin>
	<d6088dc0-42d3-30fc-5630-2f12b9b717dd@oracle.com>
	<alpine.DEB.2.20.15.1612200031460.16331@kropotkin>
	<e6543ef5-c68c-30bc-4891-c05a13725d91@oracle.com>
	<alpine.DEB.2.20.15.1612200300520.16331@kropotkin>
Message-ID: <38d4dee2-b466-0ded-8b80-dcab749489ad@oracle.com>

Hi Peter, I'm cc'ing awt-dev as the client folk should have a better 
idea how font libraries are supposed to work on windows.

David

On 20/12/2016 12:49 PM, Peter Koellner wrote:
> Thanks,
> I am not sure the debug output is helping very much. There seem to be
> lots of ClassNotFound exceptions there. I can see the window opening,
> but then nothing works.
> I have now reconfigured tzhe program did a make
> CONF=windows-x86-normal-server-fastdebug
> and then a
> $ build/windows-x86-normal-server-fastdebug/jdk/bin/java
> -XX:+TraceExceptions
> -jar e:/javatest/testjava/out/artifacts/testjava_jar/testjava.jar >
> crap.log 2>
> & 1
>
> I guess the decisive part is this:
>
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3f0684e4} 'load'
> '(Ljava/lang/String;Z)V' in 'java/lang/ClassLoader$NativeLibrary'>
>  at bci 0 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3ef4551c} 'loadLibrary0'
> '(Ljava/lang/Class;Ljava/io/File;)Z' in 'java/lang/ClassLoader>
>  at bci 328 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3ef4551c} 'loadLibrary0'
> '(Ljava/lang/Class;Ljava/io/File;)Z' in 'java/lang/ClassLoader>
>  at bci 352 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3ef4551c} 'loadLibrary0'
> '(Ljava/lang/Class;Ljava/io/File;)Z' in 'java/lang/ClassLoader>
>  at bci 398 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3ef4551c} 'loadLibrary0'
> '(Ljava/lang/Class;Ljava/io/File;)Z' in 'java/lang/ClassLoader>
>  at bci 406 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3ef45164} 'loadLibrary'
> '(Ljava/lang/Class;Ljava/lang/String;Z)V' in 'java/lang/ClassLo>
>  at bci 217 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3f00e4dc} 'loadLibrary0'
> '(Ljava/lang/Class;Ljava/lang/String;)V' in 'java/lang/Runtime>
>  at bci 54 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3ef47b14} 'loadLibrary'
> '(Ljava/lang/String;)V' in 'java/lang/System'>
>  at bci 7 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x4122072c} 'run'
> '()Ljava/lang/Object;' in 'sun/font/FontManagerNativeLibrary$1'>
>  at bci 26 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
> thrown [C:\openjdk\jdk8u\hotspot\src\share\vm\prims\jvm.cpp, line 1394]
> for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3efd3384} 'doPrivileged'
> '(Ljava/security/PrivilegedAction;)Ljava/lang/Object;' in 'jav>
>  at bci 0 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x412202f4} '<clinit>' '()V' in
> 'sun/font/FontManagerNativeLibrary'>
>  at bci 7 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
> thrown [C:\openjdk\jdk8u\hotspot\src\share\vm\oops\instanceKlass.cpp,
> line 959]
> for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x4121fd74} 'run'
> '()Ljava/lang/Object;' in 'sun/font/SunFontManager$1'>
>  at bci 0 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
> thrown [C:\openjdk\jdk8u\hotspot\src\share\vm\prims\jvm.cpp, line 1394]
> for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x3efd3384} 'doPrivileged'
> '(Ljava/security/PrivilegedAction;)Ljava/lang/Object;' in 'jav>
>  at bci 0 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
>  thrown in interpreter method <{method} {0x4121d024} '<clinit>' '()V' in
> 'sun/font/SunFontManager'>
>  at bci 40 for thread 0x00a4f400
> Exception <a 'java/lang/UnsatisfiedLinkError'> (0x2f032de8)
> thrown [C:\openjdk\jdk8u\hotspot\src\share\vm\oops\instanceKlass.cpp,
> line 959]
> for thread 0x00a4f400
>
>
>
>
> And in jdk/src/share/classes/sun/font/FontManagerNativeLibrary.java
>
>             public Object run() {
>                /* REMIND do we really have to load awt here? */
>                System.loadLibrary("awt");
>                if (FontUtilities.isOpenJDK &&
>                    System.getProperty("os.name").startsWith("Windows")) {
>                    /* Ideally fontmanager library should not depend on
>                       particular implementation of the font scaler.
>                       However, freetype scaler is basically small
> wrapper on
>                       top of freetype library (that is used in binary
> form).
>
>                       This wrapper is compiled into fontmanager and this
> make
>                       fontmanger library depending on freetype library.
>
>                       On Windows DLL's in the JRE's BIN directory cannot be
>                       found by windows DLL loading as that directory is not
>                       on the Windows PATH.
>
>                       To avoid link error we have to load freetype
> explicitly
>                       before we load fontmanager.
>
>                       Note that we do not need to do this for T2K because
>                       fontmanager.dll does not depend on t2k.dll.
>
>                       NB: consider moving freetype wrapper part to separate
>                           shared library in order to avoid dependency. */
>                    System.loadLibrary("freetype");
>                }
>                System.loadLibrary("fontmanager");
>
>                return null;
>
>
>
> So I guess it does not find awt, freetype or fontmanager libraries, so
> it probably is the freetype library. Now the configure script asked for
> the freetype lib to be installed and gave explicit instructions how to
> rename teh library - but do I have to do something with that manually so
> the runtime finds it then?
>
> The freetype.dll is located inside the bin folder, as well as awt and
> fontmanager:
>
> /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/jdk/bin
> $ ls
> appletviewer.exe  jaas_nt.dll              java-rmi.exe
> jjs.pdb         keytool.exe       pack200.exe       sunmscapi.pdb
> appletviewer.pdb  jaas_nt.pdb              java-rmi.pdb
> jli.dll         keytool.pdb       pack200.pdb       tnameserv.exe
> attach.dll        jabswitch.exe            javaw.exe
> jli.pdb         kinit.exe         policytool.exe    tnameserv.pdb
> attach.pdb        jabswitch.pdb            javaw.pdb
> jmap.exe        kinit.pdb         policytool.pdb    unpack.dll
> awt.dll           jar.exe                  jawt.dll
> jmap.pdb        klist.exe         rmic.exe          unpack.pdb
> awt.pdb           jar.pdb                  jawt.pdb
> jpeg.dll        klist.pdb         rmic.pdb          unpack200.exe
> dt_shmem.dll      jarsigner.exe            JAWTAccessBridge.dll
> jpeg.pdb        ktab.exe          rmid.exe          verify.dll
> dt_shmem.pdb      jarsigner.pdb            JAWTAccessBridge.pdb
> jps.exe         ktab.pdb          rmid.pdb          verify.pdb
> dt_socket.dll     java.dll                 JAWTAccessBridge-32.dll
> jps.pdb         lcms.dll          rmiregistry.exe   w2k_lsa_auth.dll
> dt_socket.pdb     java.exe                 JAWTAccessBridge-32.pdb
> jrunscript.exe  lcms.pdb          rmiregistry.pdb   w2k_lsa_auth.pdb
> extcheck.exe      java.pdb                 jcmd.exe
> jrunscript.pdb  management.dll    sawindbg.dll      WindowsAccessBridge.dll
> extcheck.pdb      java_crw_demo.dll        jcmd.pdb
> jsadebugd.exe   management.pdb    sawindbg.map      WindowsAccessBridge.pdb
> fontmanager.dll   java_crw_demo.pdb        jconsole.exe
> jsadebugd.pdb   mlib_image.dll    sawindbg.pdb
> WindowsAccessBridge-32.dll
> fontmanager.pdb   JavaAccessBridge.dll     jconsole.pdb
> jsdt.dll        mlib_image.pdb    schemagen.exe
> WindowsAccessBridge-32.pdb
> freetype.dll ...
>
> So maybe a problem with paths? or this .pdb file missing for
> freetype.dll? not sure what that is.
>
> It probably would be easier if FileNotFoundExceptions would actually
> give out the filename somewhere instead of a bloated stacktrace, which
> is something that really have been bothering me frequently since I wrote
> my first applet in 1996...
>
> the cc to jdk8u-dev has to wait, I still have not received the
> subscription confirmation request.
>
>
> On Tue, 20 Dec 2016, David Holmes wrote:
>
>> On 20/12/2016 9:34 AM, Peter Koellner wrote:
>>> On Tue, 20 Dec 2016, David Holmes wrote:
>>>
>>>> On 20/12/2016 7:41 AM, Peter Koellner wrote:
>>>>> How do I add jvm args to the make test java processes? localized
>>>>> windows
>>>>> 7 home can't change the locale to en, but setting -Duser.country=US
>>>>> -Duser-language=en should solve a number of i18n related test
>>>>> failures...
>>>>
>>>> It might work to run:
>>>>
>>>> make test JAVA_VM_ARGS="-Duser.country=US -Duser-language=en"
>>>
>>> Thanks. I'll do that after the next build tomorrow. Can I also increase
>>> the timeouts for the tests somehow?
>>
>> Try adding:
>>
>> JTREG_TIMEOUT_OPTION=-timeoutFactor:4
>>
>> but increase 4 to whatever you think suitable.
>>
>> BTW I'm determining this by reading jdk/test/Makefile and seeing how
>> the jtreg tests get run.
>>
>> David
>
>

From maksim.khramov at oracle.com  Tue Dec 20 11:36:54 2016
From: maksim.khramov at oracle.com (Maksim Khramov)
Date: Tue, 20 Dec 2016 14:36:54 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
Message-ID: <3d10c62d-1b83-b2c0-8762-d4abbd123be7@oracle.com>

Hello,
webrev updated: http://cr.openjdk.java.net/~avstepan/8154314/webrev.02 
<http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.02>

getScaleFactor() code is now directly used GraphicsEnviroinment code to 
get scale factor.


Thanks,
Maksim


On 19.12.2016 18:47, Maksim Khramov wrote:
> Hello,
>
> please review this request...
>
> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314
>
> Test bug. Compilation of 
> java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java 
> still fails due removed method
>
> Thanks,
> Maksim.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161220/57aa9629/attachment.html>

From sergey.bylokhov at oracle.com  Tue Dec 20 13:13:17 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Dec 2016 16:13:17 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <3d10c62d-1b83-b2c0-8762-d4abbd123be7@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
	<3d10c62d-1b83-b2c0-8762-d4abbd123be7@oracle.com>
Message-ID: <73899099-F97C-4830-B99D-1542227C0ADB@oracle.com>

> webrev updated: http://cr.openjdk.java.net/~avstepan/8154314/webrev.02 <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.02>
> 
> getScaleFactor() code is now directly used GraphicsEnviroinment code to get scale factor.
Since the "import sun.java2d.SunGraphics2D? was removed then probably "@modules java.desktop/sun.java2d? can be removed as well?

> 
> Thanks,
> Maksim
> 
> 
> On 19.12.2016 18:47, Maksim Khramov wrote:
>> Hello, 
>> 
>> please review this request... 
>> 
>> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ <http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/> 
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314 <https://bugs.openjdk.java.net/browse/JDK-8154314> 
>> 
>> Test bug. Compilation of java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java still fails due removed method 
>> 
>> Thanks, 
>> Maksim. 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161220/072d047f/attachment.html>

From maksim.khramov at oracle.com  Tue Dec 20 14:07:25 2016
From: maksim.khramov at oracle.com (Maksim Khramov)
Date: Tue, 20 Dec 2016 17:07:25 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <73899099-F97C-4830-B99D-1542227C0ADB@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
	<3d10c62d-1b83-b2c0-8762-d4abbd123be7@oracle.com>
	<73899099-F97C-4830-B99D-1542227C0ADB@oracle.com>
Message-ID: <069e9b53-2e04-170a-365e-5ba57ee8844d@oracle.com>

webrev updated: http://cr.openjdk.java.net/~avstepan/8154314/webrev.03 
<http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.03>

Removed unused module declaration


On 20.12.2016 16:13, Sergey Bylokhov wrote:
>> webrev updated: 
>> http://cr.openjdk.java.net/~avstepan/8154314/webrev.02 
>> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.02>
>>
>> getScaleFactor() code is now directly used GraphicsEnviroinment code 
>> to get scale factor.
> Since the "import sun.java2d.SunGraphics2D? was removed then probably 
> "@modules java.desktop/sun.java2d? can be removed as well?
>
>>
>> Thanks,
>> Maksim
>>
>>
>> On 19.12.2016 18:47, Maksim Khramov wrote:
>>> Hello,
>>>
>>> please review this request...
>>>
>>> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314
>>>
>>> Test bug. Compilation of 
>>> java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java 
>>> still fails due removed method
>>>
>>> Thanks,
>>> Maksim.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161220/f189c642/attachment.html>

From sergey.bylokhov at oracle.com  Tue Dec 20 15:02:58 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Dec 2016 18:02:58 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <069e9b53-2e04-170a-365e-5ba57ee8844d@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
	<3d10c62d-1b83-b2c0-8762-d4abbd123be7@oracle.com>
	<73899099-F97C-4830-B99D-1542227C0ADB@oracle.com>
	<069e9b53-2e04-170a-365e-5ba57ee8844d@oracle.com>
Message-ID: <35D78E87-4471-4CCC-A8A2-7C7C3E0E5B93@oracle.com>

Looks fine, thanks.

> 
> webrev updated: http://cr.openjdk.java.net/~avstepan/8154314/webrev.03 <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.03>
> 
> Removed unused module declaration
> 
> 
> On 20.12.2016 16:13, Sergey Bylokhov wrote:
>>> webrev updated: http://cr.openjdk.java.net/~avstepan/8154314/webrev.02 <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.02>
>>> 
>>> getScaleFactor() code is now directly used GraphicsEnviroinment code to get scale factor.
>> Since the "import sun.java2d.SunGraphics2D? was removed then probably "@modules java.desktop/sun.java2d? can be removed as well?
>> 
>>> 
>>> Thanks,
>>> Maksim
>>> 
>>> 
>>> On 19.12.2016 18:47, Maksim Khramov wrote:
>>>> Hello, 
>>>> 
>>>> please review this request... 
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/> 
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314 <https://bugs.openjdk.java.net/browse/JDK-8154314> 
>>>> 
>>>> Test bug. Compilation of java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java still fails due removed method 
>>>> 
>>>> Thanks, 
>>>> Maksim. 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161220/839359ef/attachment.html>

From semyon.sadetsky at oracle.com  Tue Dec 20 15:13:21 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 20 Dec 2016 18:13:21 +0300
Subject: <AWT Dev> [9] Review request for 8154314: [TEST_BUG]
 java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java
In-Reply-To: <35D78E87-4471-4CCC-A8A2-7C7C3E0E5B93@oracle.com>
References: <84b695cd-bad7-400c-5f68-eccd8ce15a8d@oracle.com>
	<3d10c62d-1b83-b2c0-8762-d4abbd123be7@oracle.com>
	<73899099-F97C-4830-B99D-1542227C0ADB@oracle.com>
	<069e9b53-2e04-170a-365e-5ba57ee8844d@oracle.com>
	<35D78E87-4471-4CCC-A8A2-7C7C3E0E5B93@oracle.com>
Message-ID: <0194e57f-8d08-fb74-9916-f23df49ddcfb@oracle.com>

+1

--Semyon


On 20.12.2016 18:02, Sergey Bylokhov wrote:
> Looks fine, thanks.
>
>>
>> webrev updated: 
>> http://cr.openjdk.java.net/~avstepan/8154314/webrev.03 
>> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.03>
>>
>> Removed unused module declaration
>>
>>
>> On 20.12.2016 16:13, Sergey Bylokhov wrote:
>>>> webrev updated: 
>>>> http://cr.openjdk.java.net/~avstepan/8154314/webrev.02 
>>>> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.02>
>>>>
>>>> getScaleFactor() code is now directly used GraphicsEnviroinment 
>>>> code to get scale factor.
>>> Since the "import sun.java2d.SunGraphics2D? was removed then 
>>> probably "@modules java.desktop/sun.java2d? can be removed as well?
>>>
>>>>
>>>> Thanks,
>>>> Maksim
>>>>
>>>>
>>>> On 19.12.2016 18:47, Maksim Khramov wrote:
>>>>> Hello,
>>>>>
>>>>> please review this request...
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~avstepan/8154314/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Eavstepan/8154314/webrev.01/>
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8154314
>>>>>
>>>>> Test bug. Compilation of 
>>>>> java/awt/datatransfer/DragImage/MultiResolutionDragImageTest.java 
>>>>> still fails due removed method
>>>>>
>>>>> Thanks,
>>>>> Maksim.
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161220/5c6c6306/attachment-0001.html>

From abhijit.r.roy at oracle.com  Wed Dec 21 13:02:20 2016
From: abhijit.r.roy at oracle.com (Abhijit Roy)
Date: Wed, 21 Dec 2016 05:02:20 -0800 (PST)
Subject: <AWT Dev> RFR JDK-8171836: Memory leak in
 java.desktop/unix/native/common/awt/fontpath.c
Message-ID: <f591689d-8961-4b8f-97d5-68b02f3f7290@default>

Hi all,
 
 
 
Please review the fix for the bug below:
 
Bug: https://bugs.openjdk.java.net/browse/JDK-8171836
 
Description: Memory leak in java.desktop/unix/native/common/awt/fontpath.c
 
Webrev: http://cr.openjdk.java.net/~rpatil/8171836/webrev.00/
 
 
To prevent memory leak issue, I have released the newFontPath in java.desktop/unix/native/common/awt/fontpath. 
Moving forward it for review.
 
 
 
Regards,
 
Abhijit

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161221/8c534940/attachment.html>

From vadim.pakhnushev at oracle.com  Wed Dec 21 14:17:09 2016
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Wed, 21 Dec 2016 17:17:09 +0300
Subject: <AWT Dev> RFR JDK-8171836: Memory leak in
 java.desktop/unix/native/common/awt/fontpath.c
In-Reply-To: <f591689d-8961-4b8f-97d5-68b02f3f7290@default>
References: <f591689d-8961-4b8f-97d5-68b02f3f7290@default>
Message-ID: <f8a0b013-4db8-c7ed-d1b2-5477be9fa8ee@oracle.com>

Abhijit,
I think there's some misunderstanding here.
The pointer you are trying to free is NULL already:

      if ( *newFontPath *== NULL ) {
        free ( ( void *) appendDirList );
+      free((void*) *newFontPath*);

Thanks,
Vadim

On 21.12.2016 16:02, Abhijit Roy wrote:
> Hi all,
>   
> Please review the fix for the bug below:
> Bug:https://bugs.openjdk.java.net/browse/JDK-8171836
> Description: Memory leak in java.desktop/unix/native/common/awt/fontpath.c
> Webrev:http://cr.openjdk.java.net/~rpatil/8171836/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erpatil/8171836/webrev.00/>
> To prevent memory leak issue, I have released the newFontPath in java.desktop/unix/native/common/awt/fontpath.
> Moving forward it for review.
>   
> Regards,
> Abhijit
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161221/277e77a8/attachment.html>

From devnexen at gmail.com  Wed Dec 21 14:28:50 2016
From: devnexen at gmail.com (David CARLIER)
Date: Wed, 21 Dec 2016 14:28:50 +0000
Subject: <AWT Dev> RFR JDK-8171836: Memory leak in
	java.desktop/unix/native/common/awt/fontpath.c
In-Reply-To: <f8a0b013-4db8-c7ed-d1b2-5477be9fa8ee@oracle.com>
References: <f591689d-8961-4b8f-97d5-68b02f3f7290@default>
	<f8a0b013-4db8-c7ed-d1b2-5477be9fa8ee@oracle.com>
Message-ID: <CA+XhMqxOkbbc-8NfL9GxgUGLx9v25hCssdqNkJDKtMn_VS39cw@mail.gmail.com>

Hi,

there is the original patch indeed it is not this.

Kindest regards.

On 21 December 2016 at 14:17, Vadim Pakhnushev
<vadim.pakhnushev at oracle.com> wrote:
> Abhijit,
> I think there's some misunderstanding here.
> The pointer you are trying to free is NULL already:
>
>      if ( newFontPath == NULL ) {
>        free ( ( void *) appendDirList );
> +      free((void*) newFontPath);
>
> Thanks,
> Vadim
>
>
> On 21.12.2016 16:02, Abhijit Roy wrote:
>
> Hi all,
>
>
>
>
>
>
>
> Please review the fix for the bug below:
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171836
>
>
>
> Description: Memory leak in java.desktop/unix/native/common/awt/fontpath.c
>
>
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8171836/webrev.00/
>
>
>
>
>
> To prevent memory leak issue, I have released the newFontPath in
> java.desktop/unix/native/common/awt/fontpath.
>
> Moving forward it for review.
>
>
>
>
>
>
>
> Regards,
>
>
>
> Abhijit
>
>
>
>
-------------- next part --------------
diff --git a/src/java.desktop/unix/native/common/awt/fontpath.c b/src/java.desktop/unix/native/common/awt/fontpath.c
--- a/src/java.desktop/unix/native/common/awt/fontpath.c
+++ b/src/java.desktop/unix/native/common/awt/fontpath.c
@@ -289,6 +289,7 @@
         onePath = SAFE_SIZE_ARRAY_ALLOC(malloc, strlen (fDirP->name[index]) + 2, sizeof( char ) );
         if (onePath == NULL) {
             free ( ( void *) appendDirList );
+            free ( ( void *) newFontPath );
             XFreeFontPath ( origFontPath );
             return;
         }

From abhijit.r.roy at oracle.com  Wed Dec 21 18:37:39 2016
From: abhijit.r.roy at oracle.com (Abhijit Roy)
Date: Thu, 22 Dec 2016 00:07:39 +0530
Subject: <AWT Dev> RFR JDK-8171836: Memory leak in
 java.desktop/unix/native/common/awt/fontpath.c
In-Reply-To: <f8a0b013-4db8-c7ed-d1b2-5477be9fa8ee@oracle.com>
References: <f591689d-8961-4b8f-97d5-68b02f3f7290@default>
	<f8a0b013-4db8-c7ed-d1b2-5477be9fa8ee@oracle.com>
Message-ID: <992e9bc3-2b8f-689f-b990-e7d097ae0048@oracle.com>

Hi Vadim,

Yes. I did a mistake here. Please find the correct webrev below.

Webrev: http://cr.openjdk.java.net/~rpatil/8171836/webrev.01/


Thanks
Abhijit

On 12/21/2016 7:47 PM, Vadim Pakhnushev wrote:
> Abhijit,
> I think there's some misunderstanding here.
> The pointer you are trying to free is NULL already:
>
>      if ( *newFontPath *== NULL ) {
>        free ( ( void *) appendDirList );
> +      free((void*) *newFontPath*);
>
> Thanks,
> Vadim
>
> On 21.12.2016 16:02, Abhijit Roy wrote:
>> Hi all,
>>   
>>   
>>   
>> Please review the fix for the bug below:
>>   
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8171836
>>   
>> Description: Memory leak in java.desktop/unix/native/common/awt/fontpath.c
>>   
>> Webrev:http://cr.openjdk.java.net/~rpatil/8171836/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Erpatil/8171836/webrev.00/>
>>   
>>   
>> To prevent memory leak issue, I have released the newFontPath in java.desktop/unix/native/common/awt/fontpath.
>> Moving forward it for review.
>>   
>>   
>>   
>> Regards,
>>   
>> Abhijit
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161222/96f01d21/attachment.html>

From ambarish.rapte at oracle.com  Thu Dec 22 05:35:24 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 21 Dec 2016 21:35:24 -0800 (PST)
Subject: <AWT Dev> RFR JDK-8171836: Memory leak in
 java.desktop/unix/native/common/awt/fontpath.c
In-Reply-To: <992e9bc3-2b8f-689f-b990-e7d097ae0048@oracle.com>
References: <f591689d-8961-4b8f-97d5-68b02f3f7290@default>
	<f8a0b013-4db8-c7ed-d1b2-5477be9fa8ee@oracle.com>
	<992e9bc3-2b8f-689f-b990-e7d097ae0048@oracle.com>
Message-ID: <16b4a38d-4964-430c-a0e1-bd4d30cab8f6@default>

Hi Abhijit,

                There can be references added to newFontPath[] in previous iterations of loop at Line 298: newFontPath[nPaths++] = onePath;

 

                So these references should also be freed, something similar to code at line 308:

 

                for ( index = origNumPaths; index < totalDirCount; index++ ) {

                                free( newFontPath[index] );

}

 

As many references added to newFontPath should be freed accordingly.

 

Regards,

Ambarish

 

From: Abhijit Roy 
Sent: Thursday, December 22, 2016 12:08 AM
To: Vadim Pakhnushev; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR JDK-8171836: Memory leak in java.desktop/unix/native/common/awt/fontpath.c

 

Hi Vadim,

Yes. I did a mistake here. Please find the correct webrev below.

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8171836/webrev.01/"http://cr.openjdk.java.net/~rpatil/8171836/webrev.01/


Thanks
Abhijit

On 12/21/2016 7:47 PM, Vadim Pakhnushev wrote:

Abhijit, 
I think there's some misunderstanding here.
The pointer you are trying to free is NULL already:

     if ( newFontPath == NULL ) {
       free ( ( void *) appendDirList );
+      free((void*) newFontPath);

Thanks,
Vadim

On 21.12.2016 16:02, Abhijit Roy wrote:

Hi all,
 
 
 
Please review the fix for the bug below:
 
Bug: https://bugs.openjdk.java.net/browse/JDK-8171836
 
Description: Memory leak in java.desktop/unix/native/common/awt/fontpath.c
 
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8171836/webrev.00/"http://cr.openjdk.java.net/~rpatil/8171836/webrev.00/
 
 
To prevent memory leak issue, I have released the newFontPath in java.desktop/unix/native/common/awt/fontpath. 
Moving forward it for review.
 
 
 
Regards,
 
Abhijit

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161221/1fff7df2/attachment-0001.html>

From dmitry.markov at oracle.com  Mon Dec 26 18:35:11 2016
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 26 Dec 2016 21:35:11 +0300
Subject: <AWT Dev> [9] Review request for 8171949: [macosx] AWT_ZoomFrame
	Automated tests fail with error: The bitwise mask
	Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state
Message-ID: <264E5642-84C1-4C22-902D-4346010653E6@oracle.com>

Hello,

Could you review a fix for jdk9, please?

	bug: https://bugs.openjdk.java.net/browse/JDK-8171949
	webrev: http://cr.openjdk.java.net/~dmarkov/8171949/webrev.00/

Problem description:
Current implementation of CPlatformWindow.orderAboveSiblings() performs ordering for iconified windows. That causes the following problem: if window?s state set to ICONIFIED via setExtendedState() method, the window moves to ICONIFIED state, but right after that it moves back to the previous state, (i.e. the invocation of setExtendedState() does not have any effect).

Fix:
CPlatformWindow.orderAboveSiblings() should NOT perform ordering for the windows which are already in ICONIFIED state or when iconify operation, (i.e moving to ICONIFIED state is in progress).


Thanks,
Dmitry

From prem.balakrishnan at oracle.com  Tue Dec 27 09:14:05 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Tue, 27 Dec 2016 01:14:05 -0800 (PST)
Subject: <AWT Dev> Review Request JDK:-8162959 [HiDPI] screenshot
 artifacts using AWT Robot
In-Reply-To: <868228c8-441c-c73f-6a47-0c040e17f576@oracle.com>
References: <d9e5cffb-e2cb-41d8-8557-4aa994ae99c6@default>
	<1cbc0e01-8da3-9c44-498b-f2725a9ded2d@oracle.com>
	<3234fd3e-da5f-4ef9-9b25-7604464f01c7@default>
	<a4a5fd66-0000-a0dc-c387-d757384ba477@oracle.com>
	<07dc31bf-c52a-4c86-8cd9-b62f622d4338@default>
	<85d3e709-727d-a948-bccd-3737867f974f@oracle.com>
	<b461ab16-af12-4ed3-91b7-392b3ffd66fa@default>
	<868228c8-441c-c73f-6a47-0c040e17f576@oracle.com>
Message-ID: <079fecde-5689-426a-a5f6-ea7fa8a76a40@default>

Hi Alexander,

 

Please review updated patch,

http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.04/ 

I used  wrong bounds while creating images, correct it in this patch.

 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Wednesday, December 14, 2016 5:18 PM
To: Prem Balakrishnan; Sergey Bylokhov; awt-dev at openjdk.java.net; Philip Race
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 07/12/16 10:24, Prem Balakrishnan wrote:



Hi Alexander,

 

Please review updated patch as per review comments.

HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.03/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.03/

  I used a simple app [1] to create a screenshot of a frame on Mac OS X:
        Rectangle rect = frame.getBounds();
        rect.setLocation(frame.getLocationOnScreen());
        BufferedImage img = robot.createScreenCapture(rect);

  It takes only bottom right quarter of the frame [2].

  Is it possible to use some API that makes a screenshot and returns an NSImage on Mac OS X?
  In this case it would be possible to get a high resolution representation from the NSImage and return it in the same way as it is updated on Windows and Linux.

  [1] http://cr.openjdk.java.net/~alexsch/8162959/screenshot/RobotScreenshot.java
  [2] http://cr.openjdk.java.net/~alexsch/8162959/screenshot/screenshot.png

  Thanks,
  Alexandr.



 

Regards,

Prem

 

 

From: Alexandr Scherbatiy 
Sent: Monday, November 21, 2016 8:10 PM
To: Prem Balakrishnan; Sergey Bylokhov; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Phil Race
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 11/16/2016 8:46 AM, Prem Balakrishnan wrote:




Hi Alexander, 

 

Please review update patch as per review comments.

HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.02/

 

With this patch, Robot.createScreenCapture(Rectangle) method returns a scaled down image on the HiDPI display.


- The native part on Mac OS X and Linux should be updated as well.

- 416      * Returns BufferedImage for Non-HiDPI display and MultiResolutionImage 
  417      * for HiDPI display with two resolution variants.

There should be added an explanation what is the content of the first and the second resolution variant.

Thanks,
Alexandr.





 

Regards,

Prem

 

From: Alexandr Scherbatiy 
Sent: Thursday, November 03, 2016 4:05 PM
To: Prem Balakrishnan; Sergey Bylokhov; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 11/2/2016 1:57 PM, Prem Balakrishnan wrote:





Hi Alexander,

 

Please review updated patch.

HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.01/

 

Added a new public API "Image createHiDPIScreenCapture(Rectangle screenRect)".

Returns an ordinary screenshot(BufferedImage) if the UI scale is 1.

 

Returns MultiResolutionImage for HiDPI display with two resolution variants,

1.       Low Resolution/base image with user input width and height,  I have used interpolation algorithm for scaling , adapted from JavaFX Robot (http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc),

2.       High Resolution image with scaled width and height .

  - Please, check that the Robot.createScreenCapture(Rectangle) method returns a scaled down image on the HiDPI display
  - Probably existing Java methods can be used for an image scaling.
  For example, there is the Image.getScaledInstance(int width, int height, int hints) method.
  Or may be it is better just to create an image with required size and draw the high-resolution image into it using a specific scale and rendering hints.

  Thanks,
  Alexandr.






 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Thursday, October 13, 2016 3:21 PM
To: Prem Balakrishnan; Sergey Bylokhov; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

 

On 06/10/16 15:28, Prem Balakrishnan wrote:

Hi,

 

 

Please review fix for JDK 9, 

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8162959 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/ 

 

I have adapted the same fix as used for JavaFX Robot 

Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8162783"JDK-8162783.

Patch: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc

 

 

New Public API " BufferedImage createScreenCapture(Rectangle screenRect, boolean isHiDPI)" is added,
Which will have a parameter to specify if HiDPI.

  It is better to a add public method which returns MultiResolution image on HiDPI display and  consists of two resoltion variants
   - base image which has size requested by a user
   - high-resolution image which creates an original screen capture
  
  The proposed by your algorithm can be applied to the base image. 
  For more details see JDK-8020618 [macosx] java.awt.Robot makes blurry screen captures on Retina 

  Thanks,
  Alexandr.






 
Regards,
Prem
 

 

 

 

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161227/b571c0f8/attachment-0001.html>

From sergey.bylokhov at oracle.com  Wed Dec 28 13:43:34 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 28 Dec 2016 16:43:34 +0300
Subject: <AWT Dev> [9] Review request for 8171949: [macosx]
 AWT_ZoomFrame Automated tests fail with error: The bitwise mask
 Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state
In-Reply-To: <264E5642-84C1-4C22-902D-4346010653E6@oracle.com>
References: <264E5642-84C1-4C22-902D-4346010653E6@oracle.com>
Message-ID: <1F64D41A-06F4-4342-8E0F-F8A91A9506A2@oracle.com>

Looks fine.

> 
> Hello,
> 
> Could you review a fix for jdk9, please?
> 
> 	bug: https://bugs.openjdk.java.net/browse/JDK-8171949
> 	webrev: http://cr.openjdk.java.net/~dmarkov/8171949/webrev.00/
> 
> Problem description:
> Current implementation of CPlatformWindow.orderAboveSiblings() performs ordering for iconified windows. That causes the following problem: if window?s state set to ICONIFIED via setExtendedState() method, the window moves to ICONIFIED state, but right after that it moves back to the previous state, (i.e. the invocation of setExtendedState() does not have any effect).
> 
> Fix:
> CPlatformWindow.orderAboveSiblings() should NOT perform ordering for the windows which are already in ICONIFIED state or when iconify operation, (i.e moving to ICONIFIED state is in progress).
> 
> 
> Thanks,
> Dmitry


From dmitry.markov at oracle.com  Wed Dec 28 13:53:48 2016
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 28 Dec 2016 16:53:48 +0300
Subject: <AWT Dev> [9] Review request for 8171949: [macosx]
	AWT_ZoomFrame Automated tests fail with error: The bitwise
	mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state
In-Reply-To: <1F64D41A-06F4-4342-8E0F-F8A91A9506A2@oracle.com>
References: <264E5642-84C1-4C22-902D-4346010653E6@oracle.com>
	<1F64D41A-06F4-4342-8E0F-F8A91A9506A2@oracle.com>
Message-ID: <6069E1D2-B22A-48B1-A405-ADE9DA4875B2@oracle.com>

Thank you, Sergey!
Looking for the second +1 from someone else.

Thanks,
Dmitry
> On 28 Dec 2016, at 16:43, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
>> 
>> Hello,
>> 
>> Could you review a fix for jdk9, please?
>> 
>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8171949
>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8171949/webrev.00/
>> 
>> Problem description:
>> Current implementation of CPlatformWindow.orderAboveSiblings() performs ordering for iconified windows. That causes the following problem: if window?s state set to ICONIFIED via setExtendedState() method, the window moves to ICONIFIED state, but right after that it moves back to the previous state, (i.e. the invocation of setExtendedState() does not have any effect).
>> 
>> Fix:
>> CPlatformWindow.orderAboveSiblings() should NOT perform ordering for the windows which are already in ICONIFIED state or when iconify operation, (i.e moving to ICONIFIED state is in progress).
>> 
>> 
>> Thanks,
>> Dmitry
> 


From dmitry.markov at oracle.com  Wed Dec 28 16:33:02 2016
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 28 Dec 2016 19:33:02 +0300
Subject: <AWT Dev> [9] Review request for 8171952: [macosx]
	AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog
	test fails as DummyButton on Dialog did not gain focus when clicked.
Message-ID: <F883FCED-B022-4CAB-9CC6-CC3548111EEE@oracle.com>

Hello,

Could you review a fix for jdk9, please?

	bug: https://bugs.openjdk.java.net/browse/JDK-8171952
	webrev: http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/

Problem description:
LWCToolkit.getPlatformWindowUnderMouse() looks for a window only at normal window level/layer, (i.e. NSNormalWindowLevel). However after integration of JDK-8080729 the child windows of focused window are placed to floating level, (i.e. NSFloatingWindowLevel).
So the following situation may take place: the window is in focused state and obscured by its child dialog, but the current implementation of getPlatformWindowUnderMouse() reports that the window is under mouse.

Fix:
getPlatformWindowUnderMouse() should look at all possible window levels/layers during retrieval of the topmost window under mouse.

Thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161228/4167d41b/attachment.html>

From semyon.sadetsky at oracle.com  Wed Dec 28 16:37:27 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Dec 2016 19:37:27 +0300
Subject: <AWT Dev> [9] Review request for 8171949: [macosx]
 AWT_ZoomFrame Automated tests fail with error: The bitwise mask
 Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state
In-Reply-To: <6069E1D2-B22A-48B1-A405-ADE9DA4875B2@oracle.com>
References: <264E5642-84C1-4C22-902D-4346010653E6@oracle.com>
	<1F64D41A-06F4-4342-8E0F-F8A91A9506A2@oracle.com>
	<6069E1D2-B22A-48B1-A405-ADE9DA4875B2@oracle.com>
Message-ID: <6676a4f3-e0ab-880c-6d42-ea65efdf1ebc@oracle.com>

+1

--Semyon


On 12/28/2016 4:53 PM, Dmitry Markov wrote:
> Thank you, Sergey!
> Looking for the second +1 from someone else.
>
> Thanks,
> Dmitry
>> On 28 Dec 2016, at 16:43, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Looks fine.
>>
>>> Hello,
>>>
>>> Could you review a fix for jdk9, please?
>>>
>>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8171949
>>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8171949/webrev.00/
>>>
>>> Problem description:
>>> Current implementation of CPlatformWindow.orderAboveSiblings() performs ordering for iconified windows. That causes the following problem: if window?s state set to ICONIFIED via setExtendedState() method, the window moves to ICONIFIED state, but right after that it moves back to the previous state, (i.e. the invocation of setExtendedState() does not have any effect).
>>>
>>> Fix:
>>> CPlatformWindow.orderAboveSiblings() should NOT perform ordering for the windows which are already in ICONIFIED state or when iconify operation, (i.e moving to ICONIFIED state is in progress).
>>>
>>>
>>> Thanks,
>>> Dmitry


From sergey.bylokhov at oracle.com  Thu Dec 29 17:02:24 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Dec 2016 20:02:24 +0300
Subject: <AWT Dev> [9] Review request for 8171952: [macosx]
 AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails
 as DummyButton on Dialog did not gain focus when clicked.
In-Reply-To: <F883FCED-B022-4CAB-9CC6-CC3548111EEE@oracle.com>
References: <F883FCED-B022-4CAB-9CC6-CC3548111EEE@oracle.com>
Message-ID: <22F42285-B5E6-48C7-8234-A40867A8B065@oracle.com>

Looks fine.

> 
> Hello,
> 
> Could you review a fix for jdk9, please?
> 
> 	bug: https://bugs.openjdk.java.net/browse/JDK-8171952 <https://bugs.openjdk.java.net/browse/JDK-8171952>
> 	webrev: http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/
> 
> Problem description:
> LWCToolkit.getPlatformWindowUnderMouse() looks for a window only at normal window level/layer, (i.e. NSNormalWindowLevel). However after integration of JDK-8080729 the child windows of focused window are placed to floating level, (i.e. NSFloatingWindowLevel).
> So the following situation may take place: the window is in focused state and obscured by its child dialog, but the current implementation of getPlatformWindowUnderMouse() reports that the window is under mouse.
> 
> Fix:
> getPlatformWindowUnderMouse() should look at all possible window levels/layers during retrieval of the topmost window under mouse.
> 
> Thanks,
> Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161229/7debb06d/attachment.html>

From dmitry.markov at oracle.com  Thu Dec 29 14:47:36 2016
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 29 Dec 2016 17:47:36 +0300
Subject: <AWT Dev> [9] Review request for 8171952: [macosx]
	AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog
	test fails as DummyButton on Dialog did not gain focus when clicked.
In-Reply-To: <22F42285-B5E6-48C7-8234-A40867A8B065@oracle.com>
References: <F883FCED-B022-4CAB-9CC6-CC3548111EEE@oracle.com>
	<22F42285-B5E6-48C7-8234-A40867A8B065@oracle.com>
Message-ID: <666ECE3C-D5FD-417C-AA7B-795A9C698F21@oracle.com>

Thank you for review, Sergey!
Looking for the second +1 from someone else.

Thanks in advance,
Dmitry
> On 29 Dec 2016, at 20:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
>> 
>> Hello,
>> 
>> Could you review a fix for jdk9, please?
>> 
>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8171952 <https://bugs.openjdk.java.net/browse/JDK-8171952>
>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/ <http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/>
>> 
>> Problem description:
>> LWCToolkit.getPlatformWindowUnderMouse() looks for a window only at normal window level/layer, (i.e. NSNormalWindowLevel). However after integration of JDK-8080729 the child windows of focused window are placed to floating level, (i.e. NSFloatingWindowLevel).
>> So the following situation may take place: the window is in focused state and obscured by its child dialog, but the current implementation of getPlatformWindowUnderMouse() reports that the window is under mouse.
>> 
>> Fix:
>> getPlatformWindowUnderMouse() should look at all possible window levels/layers during retrieval of the topmost window under mouse.
>> 
>> Thanks,
>> Dmitry
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161229/bd68f40c/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Dec 29 16:13:24 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Dec 2016 19:13:24 +0300
Subject: <AWT Dev> [9] Review request for 8171952: [macosx]
 AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails
 as DummyButton on Dialog did not gain focus when clicked.
In-Reply-To: <666ECE3C-D5FD-417C-AA7B-795A9C698F21@oracle.com>
References: <F883FCED-B022-4CAB-9CC6-CC3548111EEE@oracle.com>
	<22F42285-B5E6-48C7-8234-A40867A8B065@oracle.com>
	<666ECE3C-D5FD-417C-AA7B-795A9C698F21@oracle.com>
Message-ID: <668156d4-ef9b-3b39-6b79-39819b051121@oracle.com>

+1

--Semyon


On 29.12.2016 17:47, Dmitry Markov wrote:
> Thank you for review, Sergey!
> Looking for the second +1 from someone else.
>
> Thanks in advance,
> Dmitry
>> On 29 Dec 2016, at 20:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Looks fine.
>>
>>>
>>> Hello,
>>>
>>> Could you review a fix for jdk9, please?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8171952
>>> webrev: http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Edmarkov/8171952/webrev.00/>
>>>
>>> Problem description:
>>> LWCToolkit.getPlatformWindowUnderMouse() looks for a window only at 
>>> normal window level/layer, (i.e. NSNormalWindowLevel). However after 
>>> integration of JDK-8080729 the child windows of focused window are 
>>> placed to floating level, (i.e. NSFloatingWindowLevel).
>>> So the following situation may take place: the window is in focused 
>>> state and obscured by its child dialog, but the current 
>>> implementation of getPlatformWindowUnderMouse() reports that the 
>>> window is under mouse.
>>>
>>> Fix:
>>> getPlatformWindowUnderMouse() should look at all possible window 
>>> levels/layers during retrieval of the topmost window under mouse.
>>>
>>> Thanks,
>>> Dmitry
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161229/8caa5757/attachment.html>

From dmitry.markov at oracle.com  Thu Dec 29 16:18:24 2016
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 29 Dec 2016 19:18:24 +0300
Subject: <AWT Dev> [9] Review request for 8171952: [macosx]
	AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog
	test fails as DummyButton on Dialog did not gain focus when clicked.
In-Reply-To: <668156d4-ef9b-3b39-6b79-39819b051121@oracle.com>
References: <F883FCED-B022-4CAB-9CC6-CC3548111EEE@oracle.com>
	<22F42285-B5E6-48C7-8234-A40867A8B065@oracle.com>
	<666ECE3C-D5FD-417C-AA7B-795A9C698F21@oracle.com>
	<668156d4-ef9b-3b39-6b79-39819b051121@oracle.com>
Message-ID: <83B93EC1-0510-4232-931A-AD31D11EAE3E@oracle.com>

Thank you very much, Semyon!

-Dmitry
> On 29 Dec 2016, at 19:13, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> +1
> 
> --Semyon
> 
> On 29.12.2016 17:47, Dmitry Markov wrote:
>> Thank you for review, Sergey!
>> Looking for the second +1 from someone else.
>> 
>> Thanks in advance,
>> Dmitry
>>> On 29 Dec 2016, at 20:02, Sergey Bylokhov < <mailto:Sergey.Bylokhov at oracle.com>Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>> 
>>> Looks fine.
>>> 
>>>> 
>>>> Hello,
>>>> 
>>>> Could you review a fix for jdk9, please?
>>>> 
>>>> 	bug:  <https://bugs.openjdk.java.net/browse/JDK-8171952>https://bugs.openjdk.java.net/browse/JDK-8171952 <https://bugs.openjdk.java.net/browse/JDK-8171952>
>>>> 	webrev:  <http://cr.openjdk.java.net/%7Edmarkov/8171952/webrev.00/>http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/ <http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/>
>>>> 
>>>> Problem description:
>>>> LWCToolkit.getPlatformWindowUnderMouse() looks for a window only at normal window level/layer, (i.e. NSNormalWindowLevel). However after integration of JDK-8080729 the child windows of focused window are placed to floating level, (i.e. NSFloatingWindowLevel).
>>>> So the following situation may take place: the window is in focused state and obscured by its child dialog, but the current implementation of getPlatformWindowUnderMouse() reports that the window is under mouse.
>>>> 
>>>> Fix:
>>>> getPlatformWindowUnderMouse() should look at all possible window levels/layers during retrieval of the topmost window under mouse.
>>>> 
>>>> Thanks,
>>>> Dmitry
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161229/3af85125/attachment.html>