GNU bug report logs - #43882
27.1; Gnus sometimes crashes emacs 27.1 during nnir search

Previous Next

Full log

View this message in rfc822 format

From: Mikael Svahnberg <mikael.svahnberg <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 43882 <at> debbugs.gnu.org
Subject: bug#43882: 27.1; Gnus sometimes crashes emacs 27.1 during nnir search
Date: Tue, 20 Oct 2020 15:11:00 +0200

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

Hi,

Sadly, a further update.

I am now on "GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin17.7.0, NS
appkit-1561.61 Version 10.13.6 (Build 17G14033)) of 2020-10-15". This
crashes for other reasons once every other day (I haven't been able to pin
it down well enough to send a bugreport yet), but until just now it has
behaved itself wrt. the NNIR search.

... Until now, that is. I again did a search, and emacs gobbled up 100% of
a cpu for 10-odd seconds and then it crashed.

I have gone back to the default 8MB cache size just to force the issue.

What version, settings, or flags should I set up to provide as rich a
picture as possible?

/Mikael


On Thu, 15 Oct 2020 at 09:26, Mikael Svahnberg <mikael.svahnberg <at> gmail.com>
wrote:

> Hi,
>
> An update: I started emacs with the increased stack on Monday and have
> been working as normal since then except that I've been searching for
> e-mail a bit more often.
>
> Today (Thursday), emacs crashed on me again when I was searching for
> e-mail.
>
> Observations:
>  - A few minutes before it started crashing I got a spinning beach ball
> for a few seconds while composing an e-mail.
>  - The crash took much longer this time. I didn't time it, but maybe in
> the order of 10-15 minutes.
>  - During this time I observed what I could think of through the Activity
> monitor:
>  -- Emacs was consuming 100% CPU (of one CPU).
>  -- It was eating memory at a rate of 5 MB every other second
>  -- "Faults" and "UNIX system Calls" increased at a steady rate, but I
> have no idea where they started from or what is normal behaviour...
>
>
> Now, I am going to reduce the stack size again to force the issue and
> update to HEAD. Let's see if that makes any difference.
>
> /Mikael
>
> On Mon, 12 Oct 2020 at 11:45, Robert Pluim <rpluim <at> gmail.com> wrote:
>
>> >>>>> On Mon, 12 Oct 2020 09:12:56 +0200, Mikael Svahnberg <
>> Mikael.Svahnberg <at> bth.se> said:
>>     >> Do things improve if you increase your stack size using 'ulimit
>> -s'?
>>     >> MacOS has what is by modern standards a fairly small default stack.
>>     >>
>>     >> There are a couple of regexp-related fixes in master as well. Could
>>     >> you try that branch?
>>     >>
>>     >> Robert
>>
>>     Mikael> Hi,
>>
>>     Mikael> The stack size was the default 8192 kB. I have --
>> reluctantly, but in
>>     Mikael> the interest of debugging -- set it to 65532 kB via ulimit
>> and then
>>     Mikael> launched emacs from that shell.
>>
>> Why reluctantly? 64M these days is nothing in terms of memory.
>>
>>     Mikael> How can I verify from within Emacs what stack size it is
>> running with?
>>
>> You can't, but since you've launched emacs from that shell it will be
>> ok.
>>
>>     Mikael> I will keep it like this for a couple of days and see if I
>> get more
>>     Mikael> crashes. If I do, I will report and move on and upgrade to
>> HEAD.
>>
>> Thanks
>>
>> Robert
>> --
>>
>

[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.