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).
I believe you might have hit a revision that contains an issue I introduced but later corrected in NSSplitView encoding. It is worth noting that, as Fred pointed out in his response, we need better testing around GUI/AppKit applications.
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.
We just had the quarterly meeting, and we discussed this. GNUstep is already using LLVM/clang, as you likely know. The issue is that libobjc2 does not function on as wide a variety of platforms as GCC and libobjc. We have, thus, been forced to compromise to support a wider audience. The issue is that this includes many corporate interests that require this support. To suddenly deprecate it would be damaging to the project. During the meeting, we all agreed that coming up with a roadmap to move us further towards using ARC and other features of LLVM/clang would be a good thing, but this must happen over time. I will start an email thread that discusses this shortly.
One of the problems which exist with libobjc2 is that it doesn't work reliably on some *BSD platforms, and it is a bear to build on Windows in a way that is compatible with MSYS2. David is likely to chime in here and say that it is easy... but you need Visual Studio to do it and, in my experience, the DLLs created are not usable with MSYS2.
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. :-(
Harsh burn, dude. ;) Seriously, though, it may look like this from the outside, but it is not so. The project is moving in the direction you suggest, there are simply other things that are holding us back.
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).
GCC doesn't care about ObjC, that much is obvious from observing their behavior over the last several years. It would take a herculean effort to implement ARC in GCC and in libobjc.
I hope this gives you hope that we are thinking about these things. Your contributions to GNUstep have always been of the highest quality and have been and always are welcome.