Just a quick update: I went through my .emacs line by line and was able to find the culprit.

After I commented out "(follow-mode t)", Emacs has been running fine for a few hours now.

It appears the combination of org-mode, follow-mode in Emacs 27-30 running in a Debian 11/12 VM in VirtualBox 6/7 on a Windows 11 host, and a copy operation on the host, sometimes causes problems.

Thank you, Eli and Michael, for your help. I really appreciate it.

On Fri, May 17, 2024 at 1:43 PM Kun Liu <kun.liu@gmail.com> wrote:

I've tried various combinations of Debian11/12, Emacs 27/28/29/30, native-compilation yes/no. This behavior seems to be always present.

On the other hand, based on all the tests I have done, it appears that this issue happens when org-mode is loaded. I will run more tests and report back if I see it happen without org-mode.

On Fri, May 17, 2024 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 70760@debbugs.gnu.org
> Date: Fri, 17 May 2024 18:23:46 +0200
>
> But what if an event is added to the input event queue, which has an
> arbitrary format? Or an existing event has been modified? It could look
> like a D-Bus event (the car of the event is `dbus-event'), but the rest
> of the list is random. It must not come via the dbusevent.c mechanism
> I've explained above, anybody can push such an event onto then input
> event queue. But I have no idea how to debug this.

Which file descriptors do we listen to, apart of sub-processes and
inotify?