Re: crash in GUI / ProjectCenter

[Wolfgang Lux]

> Am 10.01.2023 um 18:37 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> 
> 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