Opened 8 years ago

Closed 8 years ago

#27526 closed Bug (fixed)

test_fuzzy_compiling failing on a machine with 64 cores

Reported by: Raphaël Hertzog Owned by: nobody
Component: Internationalization Version: 1.10
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

patch (4.1 KB ) - added by Raphaël Hertzog 8 years ago.

Download all attachments as: .zip

Change History (4)

comment:1 by Raphaël Hertzog, 8 years ago

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

by Raphaël Hertzog, 8 years ago

Attachment: patch added

comment:2 by Raphaël Hertzog, 8 years ago

Has patch: set

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.

comment:3 by Tim Graham, 8 years ago

Resolution: fixed
Severity: Release blockerNormal
Status: newclosed
Triage Stage: UnreviewedAccepted

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

Note: See TracTickets for help on using tickets.
Back to Top