523378 - TestDeadlockDetector and test_deadlock_detector fail on OS X

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[(no longer active)]

http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unix&logfile=1256048591.1256052170.9057.gz&buildtime=1256048591&buildname=OS%20X%2010.5.2%20mozilla-central%20leak%20test%20build&fulltext=1
OS X 10.5.2 mozilla-central leak test build on 2009/10/20 07:23:11

Running Deadlock detector correctness tests...
(missed token '###!!! ERROR: Potential deadlock detected' in output)
----------------------------------


----------------------------------

TEST-UNEXPECTED-FAIL | deadlock not detected
TEST-PASS | Sanity2
(missed token '###!!! ERROR: Potential deadlock detected' in output)
----------------------------------


----------------------------------

TEST-UNEXPECTED-FAIL | deadlock not detected
(missed token 'Re-entering Monitor after acquiring other resources' in output)
----------------------------------


----------------------------------

TEST-UNEXPECTED-FAIL | deadlock not detected
(missed token '###!!! ERROR: Potential deadlock detected' in output)
----------------------------------


----------------------------------

TEST-UNEXPECTED-FAIL | deadlock not detected
TEST-PASS | ContentionNoDeadlock
Finished running Deadlock detector correctness tests.
nsStringStats
 => mAllocCount:           2701
 => mReallocCount:            1
 => mFreeCount:            2701
 => mShareCount:              0
 => mAdoptCount:              2
 => mAdoptFreeCount:          2
make[2]: *** [check] Error 1

I can't really explain this, but I *highly* doubt that it has anything to do with the associated pushlog: <http://hg.mozilla.org/mozilla-central/rev/68490d9daf23>

Comment 1

[Chris AtLee [:catlee]]

These tests on debug builds were just enabled this morning, so it's very likely that it's unrelated to http://hg.mozilla.org/mozilla-central/rev/68490d9daf23

Comment 2

[(not currently active) Ted Mielczarek]

Disabled this test on OS X for now:
http://hg.mozilla.org/mozilla-central/rev/ebe24de601e5

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

All good on my machine, can't repro :S.

BUT, these tests take a *riDONCulously* long time to run.  Could the test subprocess perhaps be getting killed off by something?

I'm actually fine with disabling these on Mac too, because of the ridiculously long test runs.  (They're nearly instantaneous on linux.)  It's just not worth the effort to debug this; I suspect NSPR again.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Seems to still be failing.  Are the unit tests installed somewhere such that they don't get wiped out until a clobber?
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1256067791.1256069391.9162.gz
OS X 10.5.2 mozilla-central leak test build on 2009/10/20 12:43:11

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I also disabled test_deadlock_detector, which we'll make covered by the same bug:
http://hg.mozilla.org/mozilla-central/rev/b82dd427322d

Comment 6

[Jens Stutte [:jstutte]]

The old xpcshell test_deadlock_detector that was failing on macOS was converted to a gtest in bug 1313488. The gtest TestDeadlockDetector runs on macOS debug builds and has had no intermittent failures reported in over 10 years. Closing as WORKSFORME.