bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pieter van Oostrum]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Wed, 18 Mar 2020 06:17:01 +0000, Pip Cet <pipcet@gmail.com> said:
>
>     Pip> On Tue, Mar 17, 2020 at 8:59 PM Paul Eggert <eggert@cs.ucla.edu> 
> wrote:
>     >> Although I haven't been following this in detail, I'd like to suggest 
> trying a
>     >> GDB watchpoint to find the bug. Watchpoints have been invaluable to me 
> when I
>     >> debug garbage-collector and other memory management issues.
>
>     Pip> They are! Unfortunately, they require a predictable address at which
>     Pip> the corruption happens, and we don't appear to have that.
>
> You have a known address if you use rr and run in reverse.
>
> Robert
>

I have a procedure to generate a crash, but it isn't very predictable. I think 
that is because there are timers running and asynchronous processes. I get a 
different crash each time I run it.

The crash generation involves opening two large mailboxes with VM (it could be 
that one would also work). I then manipulate them both, re-sorting them in a 
different order, saving, switching between the two, sorting back to my 
preferred order, saving and closing. I have saved this procedure in a keyboard 
macro, giving it a name. I copied the definition to another Emacs session. To 
recreate the crash, I copy the definition to the new Emacs session in the 
*scratch* buffer, and I can then invoke it with C-x C-e. For the latest crash, 
I entered C-x C-e some 40 times, and went to bed. After I awoke, Emacs had not 
crashed yet. So I entered a few more C-x C-e, and then it crashed immediately. 
But it was different than the previous one. So, actually, I think it will be 
very difficult to find proper watch points.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]