Skip to content

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)

Edited by JordanTeasdale