GNU bug report logs - #38748
28.0.50; crash on MacOS 10.15.2

Previous Next

Full log

Message #83 received at 38748 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, andreyk.mad <at> gmail.com, alan <at> idiocy.org,
 jguenther <at> gmail.com, 38748 <at> debbugs.gnu.org
Subject: Re: bug#38748: 28.0.50; crash on MacOS 10.15.2
Date: Thu, 9 Jan 2020 14:10:20 +0000

On Thu, Jan 9, 2020 at 10:31 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>     Eli> Also, can I please see one backtrace with all the call-stack frames,
>     Eli> starting from 'main' and ending at 'handle_fatal_signal'?  The
>     Eli> original report shows only the top-most 511 frames, and the other one
>     Eli> has a lot of ?? (missing symbols) in it.
>
> 'bt full' backtrace attached.

At the risk of being wrong again, is it possible we're looking at two
different bugs? This looks like it might be a crash in mark_frame when
a "destroyed" frame's ->output_data.ns area is being accessed.

And, indeed, nsterm.m's ns_free_frame_resources contains:

  xfree (f->output_data.ns);

but not

  f->output_data.ns = NULL;
  f->output_method = output_initial;

or anything like them.

Previous Next

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