Closed Bug 692719 Opened 8 years ago Closed 8 years ago

Intermittent test_asyncClose_leak.xul | Looking for sqlite-LEAKED reporters - got 0, expected 3

Categories

(Toolkit :: about:memory, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=6719623&tree=Mozilla-Inbound
Rev3 Fedora 12 mozilla-inbound pgo test mochitest-other on 2011-10-06 22:35:12 PDT for push c8866ebfa3c9

12302 INFO TEST-START | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/chrome/test_asyncClose_leak.xul
12303 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/chrome/test_asyncClose_leak.xul | Looking for sqlite-LEAKED reporters - got 0, expected 3
12304 INFO TEST-END | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/chrome/test_asyncClose_leak.xul | finished in 211ms
OS: Linux → All
Oh hey, this one's my fault.  text_asyncClose_leak.xul was introduced in bug 662989.
The problem is that GC must run before the final checking is done, but presumably that's not happening despite my best efforts here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/aboutmemory/tests/chrome/test_asyncClose_leak.xul#55

Any suggestions for guaranteeing GC would be welcome!
You could try using schedulePreciseGC.  This will let you wait until the JS stack is clear before GCing, which will avoid having the conservative stack scanner mess things up.  That would be my theory as to the nature of your problem.

This patch has an example: https://bugzilla.mozilla.org/attachment.cgi?id=567639&action=diff

The keys parts are:
SimpleTest.waitForExplicitFinish();

Cu.schedulePreciseGC

then inside the schedule callback explicitly call the GC and CC, do your final test.  Then do SimpleTest.finish().
mccr8, I tried your suggestion, it's attached.  This version fails more often that it succeeds for me :(  In contrast, I've never seen the old version fail on my machine.
Attachment #568999 - Flags: feedback?(continuation)
What does the runSoon(f) thing do?  Is it running code on another thread or is it just trying to run the GC at some later time?
AIUI, it schedules |f| to be run on the main event loop.  So the overall effect of forceCollectionsThenCheck() is to schedule two calls to garbageCollect() on the main event loop followed by a call to doCheck().  It's based on some code from Jesse.
Separating the cycle collections by returns to the event loop may be necessary.  How about using schedulePreciseGC instead of runSoon to do that?  Then you get plenty of precise GCs, cycle collections, and returns to the event loop (as part of schedulePreciseGC).
Attachment #568999 - Flags: feedback?(continuation)
FWIW, my plan to fix this is to fix bug 703143, which will remove this test.  The patch is awaiting review.
Bug 703143 removed this test, so I'll be rather surprised if we get this failure again.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Bug 703143 was backed out due to crashes.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Bug 703143 landed again and stuck.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.