macOS NS GUI crash due to invalid font pointer in frame struct while marking

macOS NS GUI crash due to invalid font pointer in frame struct while marking

[Daniel Pittman]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

G'day.  I've come across a crash during GC on macOS 10.15.2, GNU Emacs
built from source, git d97a77c481ec913d8c3c24f2eecdc41a28243678.

The crash is located at:
...->mark_window->mark_vectorlike->mark_frame

In this the bad pointer is in (struct frame).output_data.ns.font, where the
pointer is wildly out of the memory map, and so crashes trying to determine
if that was marked.

I haven't yet tracked this down to a root cause, but before I invest
significant time in that I'd like to know if anyone else is investigating
this, or something similar to this?

Reproduction is, painfully, just a matter of waiting for a crash.  It seems
to be vaguely correlated to external process interactions, but can't find a
clear root cause.

I'll work to get a fix, of course, but wanted to avoid duplicating work if
someone else already has this in hand, or knows more.

Thanks!

[-- Attachment #2: Type: text/html, Size: 1085 bytes --]

Re: macOS NS GUI crash due to invalid font pointer in frame struct while marking

[Robert Pluim]

>>>>> On Thu, 23 Jan 2020 11:16:39 -0500, Daniel Pittman <slippycheeze@google.com> said:

    Daniel> G'day.  I've come across a crash during GC on macOS 10.15.2, GNU Emacs
    Daniel> built from source, git d97a77c481ec913d8c3c24f2eecdc41a28243678.

    Daniel> The crash is located at:
    ...-> mark_window->mark_vectorlike->mark_frame

    Daniel> In this the bad pointer is in (struct frame).output_data.ns.font, where the
    Daniel> pointer is wildly out of the memory map, and so crashes trying to determine
    Daniel> if that was marked.

    Daniel> I haven't yet tracked this down to a root cause, but before I invest
    Daniel> significant time in that I'd like to know if anyone else is investigating
    Daniel> this, or something similar to this?

    Daniel> Reproduction is, painfully, just a matter of waiting for a crash.  It seems
    Daniel> to be vaguely correlated to external process interactions, but can't find a
    Daniel> clear root cause.

    Daniel> I'll work to get a fix, of course, but wanted to avoid duplicating work if
    Daniel> someone else already has this in hand, or knows more.

git sh 2eb834ead401fa83270cad585a4310e2e05b8baa
commit 2eb834ead401fa83270cad585a4310e2e05b8baa
Author:     Pip Cet <pipcet@gmail.com>
AuthorDate: Mon Jan 20 17:27:43 2020 +0100
Commit:     Robert Pluim <rpluim@gmail.com>
CommitDate: Mon Jan 20 17:27:43 2020 +0100

    Clear output data pointer on NS

    * src/nsterm.m (ns_free_frame_resources): Clear the output data
    pointer to prevent attempting to reuse freed resources (Bug#38748).

diff --git a/src/nsterm.m b/src/nsterm.m
index 03754e5ae5..c1d1d41117 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1644,6 +1644,7 @@ Hide the window (X11 semantics)
   [view release];

   xfree (f->output_data.ns);
+  f->output_data.ns = NULL;

   unblock_input ();
 }

Re: macOS NS GUI crash due to invalid font pointer in frame struct while marking

[Daniel Pittman]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

I'm glad I asked, thank you so much for that.  :)

On Thu, Jan 23, 2020 at 2:10 PM Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Thu, 23 Jan 2020 11:16:39 -0500, Daniel Pittman <
> slippycheeze@google.com> said:
>
>     Daniel> G'day.  I've come across a crash during GC on macOS 10.15.2,
> GNU Emacs
>     Daniel> built from source, git
> d97a77c481ec913d8c3c24f2eecdc41a28243678.
>
>     Daniel> The crash is located at:
>     ...-> mark_window->mark_vectorlike->mark_frame
>
>     Daniel> In this the bad pointer is in (struct
> frame).output_data.ns.font, where the
>     Daniel> pointer is wildly out of the memory map, and so crashes trying
> to determine
>     Daniel> if that was marked.
>
>     Daniel> I haven't yet tracked this down to a root cause, but before I
> invest
>     Daniel> significant time in that I'd like to know if anyone else is
> investigating
>     Daniel> this, or something similar to this?
>
>     Daniel> Reproduction is, painfully, just a matter of waiting for a
> crash.  It seems
>     Daniel> to be vaguely correlated to external process interactions, but
> can't find a
>     Daniel> clear root cause.
>
>     Daniel> I'll work to get a fix, of course, but wanted to avoid
> duplicating work if
>     Daniel> someone else already has this in hand, or knows more.
>
> git sh 2eb834ead401fa83270cad585a4310e2e05b8baa
> commit 2eb834ead401fa83270cad585a4310e2e05b8baa
> Author:     Pip Cet <pipcet@gmail.com>
> AuthorDate: Mon Jan 20 17:27:43 2020 +0100
> Commit:     Robert Pluim <rpluim@gmail.com>
> CommitDate: Mon Jan 20 17:27:43 2020 +0100
>
>     Clear output data pointer on NS
>
>     * src/nsterm.m (ns_free_frame_resources): Clear the output data
>     pointer to prevent attempting to reuse freed resources (Bug#38748).
>
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 03754e5ae5..c1d1d41117 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -1644,6 +1644,7 @@ Hide the window (X11 semantics)
>    [view release];
>
>    xfree (f->output_data.ns);
> +  f->output_data.ns = NULL;
>
>    unblock_input ();
>  }
>

[-- Attachment #2: Type: text/html, Size: 2817 bytes --]