Hi, when I started looking at GNUstep as means to port macOS (then Mac OS X) applications to Linux/Windows about 15 years ago I found code that was quite buggy and that kept crashing or not working as expected on the application I tried to port at that time. I've contributed a number of patches to make the GNUstep code more robust since then. In the past few years I hadn't time to contribute much to GNUstep (real life intervening at its worst), so fast forward to last Spring when I started looking back at that old hobby and was almost instantly greeted with another crash. Not having that much of time and energy I "fixed" the problem by just reverting to some revision of GNUstep gui/back shortly before the release of 0.29. Now, having accidentally updated the code to head again I had another look at this finding one cause for the crashes in NSPopUpButtonCell after a patch by Riccardo to avoid leaking the menu associated with the cell when the cell is deallocated. The patch looks correct to me, but the problem is that it uncovers another bug: The _selectedItem may contain a dangling pointer after setting the pop up button's menu to nil. The next issue, that I'm currently unable to attribute to any particular patch, is a problem where a split view in a window loaded from a gorm file is calling a method on its delegate after that delegate (which is the window controller that has loaded the window in the first place) has been deallocated (and hence the window itself should have been closed at this point). The first of this issues has a fairly straightforward fix and for the second one I might come up with a simple fix in my application to reset the split view's delegate in the window controller's dealloc method. However, what makes this so frustrating is that dangling pointers should not be an issue in the first place in 2022. Automatic reference counting and zeroing weak pointers have been around for a few years in clang and are supported the GNUstep Objective-C runtime. However, this project prefers to stick to obsolete technology (Richard mentioned gcc 4.0 as a baseline in another comment), which means ARC and weak pointers are not an option. So IMHO, in this regard people thinking this project is for nostalgics unfortunately is a well deserved characterization of this project. :-(
Wolfgang PS I characterized gcc as obsolete technology because there is little support for Objective-C in gcc. The latest statement I seem to recall from another thread was that the gcc developers don't care about breaking objc support; but even if this weren't the case the Objective-C support is lagging far behind clang (in particular with regard to memory management, which IMO has always been one of the weak spots of Objective-C).