Date: Fri, 18 Aug 2023 18:02:46 -0400
From: Ken Brown <kbrown@cornell.edu>
Cc: 65325@debbugs.gnu.org
I can reproduce the hang. But I don't get the hang in the default build
on my system (no configure options). I'll have to play with the
configure options and try to figure out what's going on.
OK, the hang in server-tests.el [and a similar hang in
keyboard-tests.el] occurs when getchar is called at keyboard.c:3978.
This call only occurs if dbus, file notification, and threads are all
disabled, i.e., if the configure options without-dbus,
without-file-notification, and without-threads are all specified or
implied. I don't understand the keyboard code well enough to know (a)
why we reach that call to getchar in the context of the hanging tests
and (b) why getchar is only called in the absence of dbus, file
notification, and threads.
Because we have no other way to read input in such a build. The code
we have there obviously cannot handle anything but character input
from stdin, so it is a small wonder that it hangs in an ERT test.
I think this is a red herring: we should skip these tests if none of
those 3 features is available. (We could also rewrite the tests to
support such a build, but I have very little sympathy for people who
build Emacs --without-all and still want to run all the test suite
successfully, and thus I don't think this would be a worthwhile
investment of our energy and resources.)
I can work around the problem by always avoiding that getchar call on
Cygwin (i.e., by adding "&& !defined CYGWIN" at line 3972). With that
change, all tests pass on Cygwin with Bruno's configure options. But I
don't want to make that change without understanding what's going on.
Can anyone help?
I don't think it's a Cygwin-only failure. But if it is, it is also OK
to skip these tests only on Cygwin, in addition to testing the absence
of those 3 features.