bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pip Cet]

On Wed, Mar 18, 2020 at 11:38 AM Pieter van Oostrum
<pieter-l@vanoostrum.org> wrote:
> 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.

Indeed, which makes debugging on GNU/Linux a lot easier.
Unfortunately, I strongly suspect this problem is specific to macOS,
and I'm not aware of a reverse debugger for that OS.

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

I think it's because of user interaction and the events it generates...

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

Is it possible this is somehow related to mouse/keyboard interaction?
That's my prime suspect, anyway; I still think that macOS runs code
asynchronously upon receiving external events in ways that aren't
kosher, particularly if they happen during GC.

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.