--- Begin Message ---
|
Subject: |
28.0.50; Failing autorevert tests on Cygwin |
|
Date: |
Tue, 20 Jul 2021 12:26:51 -0400 |
|
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 |
Some of the autorevert tests fail on Cygwin. The precise tests that
fail aren't the same in every run, but here's the result of the most
recent run on my 64-bit Cygwin system:
Ran 8 tests, 3 results as expected, 5 unexpected (2021-07-20 11:28:04-0400,
9.783866 sec)
5 unexpected results:
FAILED auto-revert-test00-auto-revert-mode
FAILED auto-revert-test01-auto-revert-several-files
FAILED auto-revert-test02-auto-revert-deleted-file
FAILED auto-revert-test05-global-notify
FAILED auto-revert-test07-auto-revert-several-buffers
And here's the result of the most recent run on my 32-bit Cygwin system:
Ran 8 tests, 4 results as expected, 4 unexpected (2021-07-20 11:35:17-0400,
19.531540 sec)
4 unexpected results:
FAILED auto-revert-test00-auto-revert-mode
FAILED auto-revert-test01-auto-revert-several-files
FAILED auto-revert-test02-auto-revert-deleted-file
FAILED auto-revert-test05-global-notify
I also see occasional failures of
auto-revert-test03-auto-revert-tail-mode on both architectures.
test02 and test05 have apparently been failing for a long time, but I
didn't notice it prior to commit fe16248b77, because all tests were
tagged as expensive before then and so weren't run by 'make check'. The
(sporadic) failures of test00, test01, and test03 started with that
commit, so they are almost certainly due to timing issues. I'm not sure
about test07, which wasn't added until later. All I know is that it
always fails on 64-bit and occasionally fails on 32-bit. This makes me
guess that it's also a timing issue, but I suppose there could be some
other bug that's specific to 64-bit.
I'm not interested in spending a lot of time on this (or asking anyone
else to spend time on it), because I've never seen a Cygwin user
complain about auto-revert mode. (Maybe no one uses it because it's
slow.) But I would like to stop seeing the test failures.
Here's one possibility: Skip test02 and test05 on Cygwin, with a FIXME
comment indicating that they've been failing for a long time and we
don't know why. Tag test00, test01, and test03 as expensive on Cygwin,
since we would have to make the tests much slower in order for them to
pass. I'm not sure about test07.
Other suggestions?
Thanks.
Ken
In GNU Emacs 28.0.50 (build 4, x86_64-pc-cygwin, GTK+ Version 3.22.28, cairo
version 1.17.4)
of 2021-07-20 built on moufang2
Repository revision: 61c1522ddedc45d85804ff2786bd301e9b487b32
Repository branch: master
Windowing system distributor 'The Cygwin/X Project', version 11.0.12012000
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NOTIFY GFILENOTIFY PDUMPER PNG
RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#49665: 28.0.50; Failing autorevert tests on Cygwin |
|
Date: |
Tue, 27 Jul 2021 19:47:53 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Version: 28.1
Michael Albinus <Michael.Albinus@gmx.de> writes:
Hi Ken,
>>> We have the tag :unstable for such tests. You might tag all tests you're
>>> not interested in. Something like this after the docstring:
>>> :tags (when (eq system-type 'cygwin) '(:unstable))
>>> Perhaps also a comment.
>>
>> Good idea. I'll do this after you've had a chance to look at it.
>
> Will do. Next days are busy, so I cannot promise to be fast.
Finally, I've decided to compile Emacs myself on Cygwin, this allows me
to go forth and back between git revisions.
I could reproduce the problem, but I have no clear view yet what to do
with timings. So I've pushed a change to master which declares all tests
as :unstable on Cygwin, as discussed.
I'm closing this bug, but (as time permits) I'll try to do better. No
promise, and there's not too much spare time, but I hate it if code
written by me doesn't work.
>> Ken
Best regards, Michael.
--- End Message ---