GNU bug report logs - #50284
28.0.50; Emacs crashes occasionally on macOS BigSur

Previous Next

Full log

View this message in rfc822 format

From: Umar Ahmad <ahmad.umar2008 <at> yahoo.in>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 50284 <at> debbugs.gnu.org
Subject: bug#50284: 28.0.50; Emacs crashes occasionally on macOS BigSur
Date: Thu, 30 Sep 2021 02:14:06 +0530

[Message part 1 (text/plain, inline)]

Hello Eli,

Apologies for the late response here. Gmail somehow decided to categorize
the
mail as spam, only to notify me via a separate mail today when the report
was closed.

Anyway, I think you're right to point out that it was some lisp code that
was
the culprit here. I've been running emacs continuously for the last 20 days
without a crash. This closely matches the time I upgraded all the packages,
so I
think it's fair to assume that some package upgrade solved it.

I was under the assumption that any lisp code crashing emacs would be a bug
in
Emacs, but I guess we can keep this closed, considering that I can't
replicate
it now.

As far as your questions are concerned I think their answers would require a
successful replication of the bug, which isn't possible now. But, I think it
would be a good exercise for me to still go through them so that future bug
reports could be better.

> We need to know where in regex-emacs.c is the place shown in the last line
above.  Can you try establishing that?

I've no idea on how to establish that considering my rudimentary knowledge
of
C. Do you mean, running emacs with GDB enabled and adding breakpoints to
figure
this out?

> This indicates that you are using s.el, which makes tracking this bug
harder.

Oh! I see. Didn't know this could make things harder. Although, I don't
think I
can easily remove this considering many packages I have, use s.el. But, at
least
I could have limited the number of possible culprits to the packages that
depend
on s.el and used it's functions, I guess.

> And this seems to indicate a possible infinite recursion in some Lisp
program
  you were running.

Got it. Makes sense.

> So I think we need to see the full Lisp backtrace when this happens, or at
least the Lisp code which runs.

Got it. I only knew of `toggle-debug-on-error`, at the time of reporting
this
bug, that would give me a trace if there were some errors in elisp but I
didn't
know, how I could've managed to get the lisp trace when emacs crashes. I
just
discovered the /etc/DEBUG file, after going through your mail, and it seems
the
way to do this is again through GDB and running xbacktrace. Is this the
correct
understanding or is there some other way to achieve this?

Anyways, thank you for looking into this. Looking forward to your responses
here. Would be great if you could give me a few pointers about these.

Regards,
Umar Ahmad



On Wed, Sep 29, 2021 at 9:31 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > So I think we need to see the full Lisp backtrace when this happens,
> > or at least the Lisp code which runs.
>
> This was a month ago, and there was no response, so I guess it sounds
> unlikely that there'll be further progress here, and I'm closing this
> bug report.  (If further progress can be made, please respond to the
> debbugs address and we'll reopen.)
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>


-- 
Regards,
Umar Ahmad

[Message part 2 (text/html, inline)]

Previous Next

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