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.bylok...@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.
