[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39962: 27.0.90; Crash in Emacs 27.0.90

From: Pieter van Oostrum
Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 19 Mar 2020 22:30:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (darwin)

Pip Cet <address@hidden> writes:

> On Thu, Mar 19, 2020 at 7:17 PM Pieter van Oostrum
> <address@hidden> wrote:
>> I had my keyboard macro translated to an Elisp function and then
>> called this a 100 times with dotimes. However, there was no crash,
>> even though I had the smaller stack size.
>> In total I had the macro run some 300+ times without any crash. I just
>> had it run automatically (put it in a .el file, and used emacs -Q -l
>> testfile.el), so no keyboard/mouse interaction.
> Did you use emacs -Q to produce the original crash, or just emacs? I
> ask because it's possible something in your mode line specification
> caused or exacerbated the problem.

The original crash was without -Q, i.e. my normal production Emacs. I have 
quite an elaborate init.el file, so it could be almost anything.

With the test described above, I used -Q -l testfile.el
I also redid that test with most of my init.el copied into the test,el, and 
that still did not cause a crash.

>> > If I'm right, it should be possible to trigger the bug by creating a
>> > reasonably large session, running (garbage-collect) in an infinite
>> > loop, and interacting with the mouse and keyboard while that is
>> > happening. Or running your keyboard macro in a similar loop, of
>> > course.
>> But if I do it in a loop it will not react to the keyboard/mouse. Do
>> you think the asynchronous processing of these events will be
>> sufficient, even though no action is taken on these events?
> I think so, but I'm not sure. I've been looking at this code for a
> while, and I think the likeliest culprit is the mouse-over
> highlighting code, possibly for the mode line. On GNU/Linux, the
> behavior is quite odd: for the first second or so after starting a
> loop, the mode line elements react to mouseover events, but not
> afterwards. On the other hand, a millisecond delay ought to be enough
> to catch it during the first second.
OK, with the next test I will try to trigger that. Right now I am compiling 
with the new 0001-more-debugging.patch.
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]