<AWT Dev> [14] Review Request: 8234522 [macos] Crash with use of native file dialog

[Sergey Bylokhov]

Hi, Dmitry.

We probably can replace NSApplicationDefined by NSEventTypeApplicationDefined, but then we will need
to replace NSApplicationDefinedMask by NSEventMaskApplicationDefined, and probably something else.
So I leave it for some future deprecation-cleanup.

On 12/10/19 4:03 am, Dmitry Markov wrote:
> Hi Sergey,
> 
> The changes look OK, but I have a few remarks. I would recommend using NSEventTypeApplicationDefined due to deprecation of NSApplicationDefined. Also it would be good to add some kind of summary to the regression test. I do not need a new webrev with suggested changes.
> 
> Thanks,
> Dmitry
> 
>> On 6 Dec 2019, at 23:05, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
>>
>> Hello.
>> Please review the fix for JDK 14.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234522
>> Fix: http://cr.openjdk.java.net/~serb/8234522/webrev.00
>>
>> This bug is tricky, we have a special mechanism to postpone deallocation
>> of the objects on the Appkit thread.
>> It solves the next problem: the native window pointer is disposed in the
>> inner AppKit loop, while it is still referenced on the stack in the native
>> Cocoa method which caused the mentioned inner loop. When the inner loop is
>> exited Cocoa crashes while dereferencing this window pointer.
>>
>> This mechanism is implemented via posting NSEvent using NSApplicationDefined
>> type and filter out this event in the nested event loop.
>>
>> But for some reason, macOS send us exactly the same event(type+subtype), which
>> we try to use for deallocation and of course, this attempt will crashes.
>> (probably because all constants of NSEvent we use were deprecated?)
>>
>> In the fix I have added additional marks(via data fields) to the event to make
>> it easy to check it was created by us, also I have bump the initial value of
>> subtype to minimize possible collisions.
>>
>>
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.