From: Daniel Pittman <slippycheeze@google.com>
To: Robert Pluim <rpluim@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: macOS NS GUI crash due to invalid font pointer in frame struct while marking
Date: Fri, 24 Jan 2020 10:04:00 -0500 [thread overview]
Message-ID: <CAC45yQuaHHnRSS+2TVMZ6iE=4V=oeOBGbus1ms0vobhZ4aGMig@mail.gmail.com> (raw)
In-Reply-To: <m2pnfaat0s.fsf@gmail.com>
[-- 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 --]
prev parent reply other threads:[~2020-01-24 15:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 16:16 macOS NS GUI crash due to invalid font pointer in frame struct while marking Daniel Pittman
2020-01-23 19:10 ` Robert Pluim
2020-01-24 15:04 ` Daniel Pittman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC45yQuaHHnRSS+2TVMZ6iE=4V=oeOBGbus1ms0vobhZ4aGMig@mail.gmail.com' \
--to=slippycheeze@google.com \
--cc=emacs-devel@gnu.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).