GWindow leaves Ghost Windows on all MacOS Versions
https://cdn.discordapp.com/attachments/438699820291457035/984538110815789136/2022-06-09_15-20-04.mp4 https://cdn.discordapp.com/attachments/438699820291457035/984504637665214504/2022-06-09_13-08-13.mp4
The two attached videos show footage of two instances of Gateware's test suite running in MacOS Monterey. There is a chance for GWindow to crash inside of macutils due to an incorrect closing procedure. I suspect this is also a race condition within the GWindow unit test, as commenting out the include for GWindowtest.hpp prevents the crashing entirely.
-
GWindow race condition needs to be resolved -
Unit tests successfully all pass on Monterey
The destructor process for GWindow on MacOS involves two functions inside macutils.h, those functions being RUN_ON_UI_THREAD, and FlushMacEventLoop(). RUN_ON_UI_THREAD takes in a lambda function, then executes the lambda if the function is on the main thread, otherwise the thread it put into a sync function to wait. FlushMacEventloop calls an objective-C function that returns an Event pointer that is then used to close the window. The specific function that crashes inside of Flush Mac event loop is highlighted below
Apple's Example for nextEventMatchingMask:
- (NSEvent *)nextEventMatchingMask:(NSEventMask)mask untilDate:(NSDate *)expiration inMode:(NSRunLoopMode)mode dequeue:(BOOL)deqFlag;
Our Implementation as of 06/20/2022:
NSEvent* event = [NSApp nextEventMatchingMask : NSEventMaskAny untilDate : [NSDate distantPast] inMode : NSDefaultRunLoopMode dequeue : YES];
Setting event to "nil" does prevent crashing, however the windows will never close and leak memory as a result.
Resources:
https://developer.apple.com/documentation/appkit/nsapplication/1428485-nexteventmatchingmask (nextEventMatchingMask) https://chritto.wordpress.com/2012/12/20/updating-the-ui-from-another-thread/ (RUN_ON_UI_THREAD)