<AWT Dev> [9] Review request for 7155957: closed/java/awt/MenuBar/MenuBarStress1/MenuBarStress1.java hangs on win 64 bit with jdk8

[Sergey Bylokhov]

Hi, Semyon.
The fix looks fine to me.
Thanks!

On 21.04.15 11:37, Semyon Sadetsky wrote:
> Sergey,
>
> done.
> http://cr.openjdk.java.net/~ssadetsky/7155957/webrev.01/
>
> --Semyon
>
> On 4/16/2015 6:41 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> Please mark all related fields in WObjectPeer as volatile( pData/ 
>> destroyed/etc). Probably MenuComponent.font field also?
>> That could be a reason for similar random issues.
>>
>> On 15.04.15 17:38, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9.
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/7155957/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-7155957
>>>
>>> *THE ROOT CAUSE
>>> A number of concurrency bugs in AWT Toolkit.
>>> When menus are modified concurrently there is a big chance that the 
>>> internal Windows menu events are handled at the same time on the 
>>> AWT-Windows thread which is not synchronized. If the internal event 
>>> processing on AWT-Windows calls Java side methods the JVM can die 
>>> silently.
>>>
>>> *SOLUTIONS
>>> A number of fixes in various Java and C++ classes are introduced to 
>>> eliminate (with finite probability) concurrency problems :
>>>
>>> 1. java.awt.Menu.remove(int)
>>>
>>> The peer.delItem(index) is called after mi.removeNotify(). That 
>>> means that dispose event will be sent earlier than the menu remove 
>>> WinAPI call. This causes Access Violation exception because Windows 
>>> events may come with deallocated references.
>>> The solution is to call them in the right order.
>>>
>>> 2. java.awt.MenuBar.remove(int)
>>> Same error as in 1 for menu bar.
>>>
>>>
>>> 3. java.awt.MenuComponent.serFont(Font)
>>> This method should hold tree lock while running otherwise its 
>>> concurrent execution causes Access Violation in number of places and 
>>> JVM is crashed.
>>>
>>> 4. awt_Menu.cpp
>>> AwtMenu::GetItem(jobject target, jint index), AwtMenu::DrawItems(), 
>>> AwtMenu::MeasureItems(
>>>
>>> Calling java.awt.Menu.getItem() during internal windows event 
>>> processing can throw ArrayIndexOutOfBoundException because number of 
>>> menu items could be changed concurrently and the index is not in 
>>> range. This causes a hidden exception which is only seen in debug 
>>> mode as an Assertion error.
>>>
>>> Another issue here is request to GetPeerForTarget() for the menu 
>>> item peer which can be concurrently deleted on the Java side as 
>>> result of Menu.delNotify() execution. It causes NPE peer which is 
>>> also hidden and only reveals itself as an Assertion error in debug 
>>> mode.
>>>
>>> The solution for all is to abort and return windows event callback 
>>> if the menu structure was changed concurrently.
>>>
>>> 5. awt_MenuBar.cpp AwtMenuBar::GetItem()
>>>
>>> Same solution as 4 for menu bar in similar situations.
>>>
>>> 6. awt_MenuItem.cpp AwtMenuItem::Dispose()
>>>
>>> The "destroyed" filed should be set for the peer before pData is set 
>>> to NULL otherwise "NPE null pData" can be thrown in various 
>>> concurrent situations.
>>>
>>> 7. awt_new.cpp safe_ExceptionOccurred()
>>>
>>> This routine is called evrywere in the code to check exceptions. It 
>>> only stops execution and prints to console if OOE happened, but 
>>> other exceptions are re-thrown silently and execution continues 
>>> without any warnings. If the call is initiated by an internal 
>>> Windows event callback the exceptions are hidden in the release mode 
>>> and shown in the debug mode as the Assertion Error message box, but 
>>> in the last case without any useful information because 
>>> GetLastError() is always 0 in such situations.
>>> I have added env->ExceptionDescribe() to print exception stack trace 
>>> on the console for all debug and release modes. This should help to 
>>> detect internal toolkit issues during testing by JCK and jtreg. 
>>> Later before the JDK9 release we can leave it for debug mode only.
>>>
>>> *A KNOWN PROBLEM DID NOT FIXED
>>> When font is assigned to a menu item concurrently there is a big 
>>> chance that menu item size will be calculated with one font while 
>>> drawing of the item will be performed with another font. In such 
>>> situation label of the menu item does not fit its size or vice versa.
>>> This is due to nature how the Windows OS handles owner-drawn menus.
>>>
>>> --Semyon
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

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