test_fuzzy_compiling failing on a machine with 64 cores

[Raphaël Hertzog]

Hello,

in Debian we recently got a bugreport which essentially boils down to a test suite failure when run with default parallel option on a machine with 64 cores and the failing test is this one:

======================================================================
FAIL: test_fuzzy_compiling (i18n.test_compilation.FuzzyTranslationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
    testMethod()
  File "/<<PKGBUILDDIR>>/tests/i18n/test_compilation.py", line 218, in test_fuzzy_compiling
    self.assertEqual(ugettext('Lenin'), force_text('Ленин'))
  File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/usr/lib/python2.7/unittest/case.py", line 924, in assertMultiLineEqual
    self.fail(self._formatMessage(msg, standardMsg))
  File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
    raise self.failureException(msg)
AssertionError: u'Lenin' != u'\u041b\u0435\u043d\u0438\u043d'
- Lenin
+ \u041b\u0435\u043d\u0438\u043d

The original bug report is here: ​https://bugs.debian.org/844139
The test was run on a big Amazon EC2 instance (not sure which one exactly) if you want to try to reproduce it.

[Raphaël Hertzog]

In fact I reproduce the above problem on each run as long as I run at least 4 parallel test runners with ./runtests.py --verbosity=2 i18n.test_compilation --parallel=4.

But with --parallel=1, the problem is gone.

In fact most of the tests in that test_compilation unit are not parallel-friendly as they create/remove the same set of files in setUp(). On multiple runs of the above commande I can randomly get other failures such as this one:

======================================================================
FAIL: test_multiple_locales (i18n.test_compilation.MultipleLocaleCompilationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
    testMethod()
  File "/home/rhertzog/deb/pkg/python-django/tests/i18n/test_compilation.py", line 112, in test_multiple_locales
    self.assertTrue(os.path.exists(self.MO_FILE_FR))
  File "/usr/lib/python2.7/unittest/case.py", line 422, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true

[Raphaël Hertzog]

Apparently this is already fixed in master due to bb7bb379e8cd91a91336946829519d64e919a1d2 and faeeb84edfebecf5a5f40df9ef816e5f1cd457c6. I suggest that you backport those two.

I have attached a patch of my own that basically did something similar to faeeb84edfebecf5a5f40df9ef816e5f1cd457c6.

[Tim Graham]

I backported the commits you mentioned to 1.10.x in c1bd4679e896301dd26f0bb51d905a194eb358b7 and a079d5ceed0cd1282db433c69135d2e082dacf0b.