GNU bug report logs - #59794
29.0.60; NSport segfaults when a fullscreen frame is being closed

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 59794 <at> debbugs.gnu.org, Kai Ma <justksqsf <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#59794: 29.0.60; NSport segfaults when a fullscreen frame is being closed)
Date: Mon, 05 Dec 2022 09:10:04 +0800

Daniel Martín <mardani29 <at> yahoo.es> writes:

> Kai Ma <justksqsf <at> gmail.com> writes:
>
>>
>> diff --git a/src/nsterm.m b/src/nsterm.m
>> index 507f2a9e7d..f99d7cde3c 100644
>> --- a/src/nsterm.m
>> +++ b/src/nsterm.m
>> @@ -6703,8 +6703,18 @@ - (BOOL)acceptsFirstResponder
>>  
>>  - (void)resetCursorRects
>>  {
>> -  NSRect visible = [self visibleRect];
>> -  NSCursor *currentCursor = FRAME_POINTER_TYPE (emacsframe);
>> +  NSRect visible;
>> +  NSCursor *currentCursor;
>> +
>> +  /* FIXME: [resetCursorRects:] can be called from the event loop
>> +     after the frame is deleted.  When this happens,
>> +     emacsframe->output_data is NULL.  This means there is an
>> +     underlying leak of the EmacsView object!  (bug#59794) */
>> +  if (! emacsframe || ! FRAME_OUTPUT_DATA (emacsframe))
>
> Wouldn't it be more clear to check !FRAME_LIVE_P (emacsframe) instead?
> (I can't reproduce this bug, so I don't know if that would avoid the
> crash.)  There is a similar check in - (void)windowWillExitFullScreen
> and - (void)windowDidExitFullScreen, for example.

Those other calls are a serious problem too.  They obscure an underlying
memory leak, and if emacsframe is not set to NULL by the point they are
called, they could result in use-after-frees once GC deletes emacsframe
entirely.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.