Re: crash in GUI / ProjectCenter

> Am 10.01.2023 um 18:37 schrieb Riccardo Mottola <[email protected]>:
> 
> Your fix appears to work
> 
> 
> I still wonder if the bug is in GNUstep which shouldn't be "picky" about this delegate or something done in ProjectCenter is fishy, something with the editor instantiation.
> 
> Observations:
> 1) open a project. Do not select any file. There is already a splitview with a generic text scroll view at the bottom. Yet closing the project window now, does not cause issues
> 2) open a project. select a file so that the editor opens. then from the menu do "close file", the status of 1) returns... and closing makes no issues
> 3) the fact that nilling the splitview delegates "macht mich stutzig"

I've seen the very same crash that you reported happen in another application, so I'm fairly confident it is a GNUstep bug. :-)
It seems difficult to reproduce, though. I've seen the crash happen with that other application only when quitting the application with sufficiently many Windows still open. Just closing a single window works fine. It also happens on Debian 11 under Gnome but not on OpenSUSE with KDE. But then, triggering the bug seems to involve at least one race condition, namely that the Window manager sends an event to the Window after it has been closed from the UI, but while its backend connection is still alive (and also while the delegate of the split view has gone already).

I'm not so sure about my suggested fix/hack. Certainly, it does the job and I don't see a reason why a window should be updating its cursor rectangles after the window has been closed (at least if it is supposed to be released at that point). Another option would likely be to close the backend connection more swiftly when a window is closed. For instance, in -[NSWindow orderWindow:relativeTo:] we might change the last condition from
  else if ([self isOneShot])
to
  else if ([self isOneShot] || (_f.has_closed && _f.is_released_when_closed))
to close the backend window immediately rather than waiting for this to happen from an autorelease pool.

One thing that is worrying is that you saw a crash even when resetting the delegates in the dealloc method. The stacktrace looks like -[NSWindow resetCursorRects] gets called for a window with a corrupted view hierarchy where a child window seems to have been deallocated while it is still present in the hierarchy. This is something that should never happen (at least not where sendEvent: can possibly be called). So maybe there is some other memory management bug at play here.

Wolfgang