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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: rpluim <at> gmail.com, andreyk.mad <at> gmail.com, alan <at> idiocy.org, jguenther <at> gmail.com, 38748 <at> debbugs.gnu.org
Subject: bug#38748: 28.0.50; crash on MacOS 10.15.2
Date: Fri, 10 Jan 2020 11:33:06 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 10 Jan 2020 09:22:30 +0000
> Cc: rpluim <at> gmail.com, alan <at> idiocy.org, jguenther <at> gmail.com, 
> 	andreyk.mad <at> gmail.com, 38748 <at> debbugs.gnu.org
> 
> > I still think the shortest way to finding the culprit here is to
> > patiently and painfully go over the last_marked array, deciphering
> > the Lisp object we marked, until we succeed in identifying the Lisp
> > data structure which got corrupted.  Once we succeed in identifying
> > that data structure, it should be relatively easy to find who and
> > where corrupts it.  This may mean a lot of inconvenient drudgery,
> > exacerbated by the fact that having a functional GDB on macOS is not
> > easy, but I don't think we have a better way at this point.
> 
> I disagree. The patch to nsterm.m is obviously harmless, and appears
> to fix the one bug we have clear evidence of, in a way that seems
> logical and necessary to me.

I wasn't talking about that part (I agree that fix should be
installed), but again, it's unrelated to the initialization of 'ok'.

Previous Next

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