Re: crash in GUI / ProjectCenter

[Riccardo Mottola]

Hi Wolfgang!


I had a nice hacking session with Fred this evening and ... fresh 
mind, new fixes.!


I found the memory issue - there was an issue with subview! 
ProjectCenter had some complex code where a subview was released 
twice.
I was able to refactor things and keep vars more localy and fix that. 
Thanks for the "hint".


On 2023-01-11 12:46:36 +0100 Wolfgang Lux  
wrote:





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.


now the delegate problem remains "only". I am able to work-around this 
now, with this patch:


+++ b/Framework/PCProjectWindow.m
@@ -260,6 +260,8 @@
 - (void)dealloc
 {
   [[NSNotificationCenter defaultCenter] removeObserver:self];
+  [h_split setDelegate:nil];
+  [v_split setDelegate:nil];
   [projectWindow close];

   [super dealloc];

unsetting the delegate and fixing the view release issue.. solves the 
crash, at least for ProjectCenter.

Where else where you experiencing the issue?

We need to think if this delegate-to-nil fix is proper of GUI orthe 
GUI code is safe and the work-around in ProjectCenter is fine. 
However, if you noticed things elsewhere, we might need to check.


What's your point? Fred?

Riccardo

--
Sent with pride with GNUMail running on GNUstep on Debian GNU/Linux on 
a SunFire with Niagara SPARC64.

Re: crash in GUI / ProjectCenter

[Wolfgang Lux]

> Am 10.01.2023 um 18:37 schrieb Riccardo Mottola :
> 
> 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

Re: crash in GUI / ProjectCenter

[Riccardo Mottola]

Hi Wolfgang,

Happy new Yar, nice to read back from you.


Wolfgang Lux wrote:

Apart from that, the problem is that you've closed the editor window and the 
editor object has been released and deallocated, but the editor window still 
exists and is still receiving events after the window has been closed. While 
-[NSWindow sendEvent:] ignores most events for closed windows is does still 
accept NSAppKitDefined events (for instance, your window manager could post a 
window moved event; I've seen that happening under Gnome for windows after they 
were closed). If for some reason the cursor rectangles of that window have been 
invalidated, sendEvent: will reset all cursor rectangles. Now if the window 
happens to contain a split view, that split view will ask its delegate for the 
size of the divider. Unfortunately, though, in this case the delegate has been 
deallocated (without the relevant pointer being reset) and hence the program 
crashes.


So you think it is the split view delegate. We came to a similar conclusion.

I had a quick different attempt: in PCProjectWindow (which is actually 
more the controller, I think... perhaps ot should be renamed). In 
deallock, I try to set


  [h_split setDelegate:nil];
  [v_split setDelegate:nil];

before propagating [projectWindow close].

That make sthe stactrace change from:

#0  0x76e267ae in objc_msg_lookup () from 
/Local/Library/Libraries/libobjc.so.4
#1  0x77b5ba6f in -[NSSplitView _dividerRectForIndex:] 
(self=0x55c98a98, _cmd=, index=0)

    at NSSplitView.m:107
#2  0x77b5e2e7 in -[NSSplitView resetCursorRects] 
(self=0x55c98a98, _cmd=)

    at NSSplitView.m:1399
#3  0x77bcd31f in resetCursorRectsForView 
(theView=0x55c98a98) at NSWindow.m:3002
#4  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#5  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#6  0x77bcfba1 in -[NSWindow resetCursorRects] 
(self=0x56257fe8, _cmd=) at NSWindow.m:3189
#7  0x77bd0ede in -[NSWindow sendEvent:] (self=0x56257fe8, 
_cmd=, theEvent=0x55e03c08)

    at NSWindow.m:4073
#8  0x77a37e6e in -[NSApplication run] (self=0x5591c158, 
_cmd=) at NSApplication.m:1585
#9  0x77a17dd9 in NSApplicationMain (argc=, 
argv=) at Functions.m:119

#10 0x76c5018a in ?? () from /lib64/libc.so.6
#11 0x76c50245 in __libc_start_main () from /lib64/libc.so.6
#12 0x55561171 in _start ()

to


#0  0x76e26732 in objc_msg_lookup () from 
/Local/Library/Libraries/libobjc.so.4
#1  0x77bcd317 in resetCursorRectsForView 
(theView=0x56007cb8) at NSWindow.m:3002
#2  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#3  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#4  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#5  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#6  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#7  0x77bcd3bc in resetCursorRectsForView (theView=out>) at NSWindow.m:3017
#8  0x77bcfba1 in -[NSWindow resetCursorRects] 
(self=0x5618aa48, _cmd=) at NSWindow.m:3189
#9  0x77bd0ede in -[NSWindow sendEvent:] (self=0x5618aa48, 
_cmd=, theEvent=0x5617c4b8)

    at NSWindow.m:4073
#10 0x77a37e6e in -[NSApplication run] (self=0x55933f48, 
_cmd=) at NSApplication.m:1585
#11 0x77a17dd9 in NSApplicationMain (argc=, 
argv=) at Functions.m:119

#12 0x76c5018a in ?? () from /lib64/libc.so.6
#13 0x76c50245 in __libc_start_main () from /lib64/libc.so.6
#14 0x55561171 in _start ()

The splitview is out, but there is still something invalid.



I'm not really familiar with the cursor rectangle code, but it seems to me that 
there is no point resetting the cursor rectangles after a window has been 
closed. With a little bit of luck, just changing the condition
   !_f.cursor_rects_valid
in line 4071 of NSWindow.m (fairly at the beginning of the -[NSWindow 
sendEvent:] method) into
   !_f.cursor_rects_valid && !_f.has_closed
should be enough to fix this issue. And hopefully it doesn't break anything for 
windows that aren't released upon closing. But it's worth reviewing that the 
cursor rectangles will be reset when such a window is opened again.


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 

Re: crash in GUI / ProjectCenter

[Wolfgang Lux]

> Am 10.01.2023 um 01:42 schrieb Riccardo Mottola :
> 
> Hi,
> 
> 
> Riccardo Mottola wrote:
>> y to understand if this is more a GUI or a ProjectCenter issue 
> 
> I checked this a little more, also with Fred. The SplitView looses its 
> delegate.. it must be one of the subviews. I suppose the Editor subview, 
> because it happens only if a proper editor is loader.
> Editor loading is a bit complex since the Framework loads some editor Bundles.
> The Editor itself can function both as in-window and in-project...
> 
> Anyone has a good clue?


Yes. It's 2023 (happy new year, btw). Use an up to date compiler and declare 
the delegate as a zeroing weak reference.


Apart from that, the problem is that you've closed the editor window and the 
editor object has been released and deallocated, but the editor window still 
exists and is still receiving events after the window has been closed. While 
-[NSWindow sendEvent:] ignores most events for closed windows is does still 
accept NSAppKitDefined events (for instance, your window manager could post a 
window moved event; I've seen that happening under Gnome for windows after they 
were closed). If for some reason the cursor rectangles of that window have been 
invalidated, sendEvent: will reset all cursor rectangles. Now if the window 
happens to contain a split view, that split view will ask its delegate for the 
size of the divider. Unfortunately, though, in this case the delegate has been 
deallocated (without the relevant pointer being reset) and hence the program 
crashes.

I'm not really familiar with the cursor rectangle code, but it seems to me that 
there is no point resetting the cursor rectangles after a window has been 
closed. With a little bit of luck, just changing the condition
  !_f.cursor_rects_valid
in line 4071 of NSWindow.m (fairly at the beginning of the -[NSWindow 
sendEvent:] method) into
  !_f.cursor_rects_valid && !_f.has_closed
should be enough to fix this issue. And hopefully it doesn't break anything for 
windows that aren't released upon closing. But it's worth reviewing that the 
cursor rectangles will be reset when such a window is opened again.

Wolfgang

Re: crash in GUI / ProjectCenter

[Riccardo Mottola]

Hi,


Riccardo Mottola wrote:
y to understand if this is more a GUI or a ProjectCenter issue 


I checked this a little more, also with Fred. The SplitView looses its 
delegate.. it must be one of the subviews. I suppose the Editor subview, 
because it happens only if a proper editor is loader.
Editor loading is a bit complex since the Framework loads some editor 
Bundles.

The Editor itself can function both as in-window and in-project...

Anyone has a good clue?

Riccardo