Since the landing of the fix to bug 803688, there appears to be constant bustage on Linux leak test builds. Assertion failure: isEmpty(), at ../../dist/include/mozilla/LinkedList.h:258 TEST-UNEXPECTED-FAIL | runtest.py | Exited with code -11 during test run make: *** [mailbloat] Error 245 Example log file: https://tbpl.mozilla.org/php/getParsedLog.php?id=16659120&full=1&branch=comm-central

Likely benign, same sort of thing as bug 805207.

I see this as the last output when running account manager tests in Thundebird: ###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0', file /var/SSD/TB-hg/mozilla/xpcom/build/nsXPComInit.cpp, line 669 UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x014E0901] UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0024AA75] UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x00251FC8] XRE_main+0x000000A7 [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x00252188] UNKNOWN [../../.././mozilla/dist/bin/thunderbird +0x00001E81] Assertion failure: isEmpty(), at ../../dist/include/mozilla/LinkedList.h:258 Not sure if it is related but it causes TB to crash. This is a debug build.

(In reply to :aceman from comment #2) > I see this as the last output when running account manager tests in > Thundebird: > ###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == > 0', file /var/SSD/TB-hg/mozilla/xpcom/build/nsXPComInit.cpp, line 669 > UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x014E0901] > UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0024AA75] > UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x00251FC8] > XRE_main+0x000000A7 [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so > +0x00252188] > UNKNOWN [../../.././mozilla/dist/bin/thunderbird +0x00001E81] > Assertion failure: isEmpty(), at ../../dist/include/mozilla/LinkedList.h:258 > > Not sure if it is related but it causes TB to crash. This is a debug build. Has your build got the fix to bug 805207 in it?

How can I find out? But I am updated to today's trunk (of mozilla-central/comm-central).

(In reply to :aceman from comment #4) > How can I find out? > But I am updated to today's trunk (of mozilla-central/comm-central). Well it landed on 1st November, so, yes, your build should have it. mozilla/xpcom/base/ClearOnShutdown.h should have: #include "mozilla/StaticPtr.h"

It does. What next?

Get a backtrace for the MOZ_ASSERT that's failing?

(gdb) bt #0 0xb755fc3c in nanosleep () from /lib/libc.so.6 #1 0xb755fa74 in sleep () from /lib/libc.so.6 #2 0xb460dc6a in ah_crap_handler (signum=11) at /var/SSD/TB-hg/mozilla/toolkit/xre/nsSigHandlers.cpp:87 #3 0xb461264e in nsProfileLock::FatalSignalHandler (signo=11, info=0xbfaf3ddc, context=0xbfaf3e5c) at /var/SSD/TB-hg/tbird-bin/mozilla/toolkit/profile/nsProfileLock.cpp:190 #4 <signal handler called> #5 0xb4793660 in ~LinkedList (this=<optimized out>, __in_chrg=<optimized out>) at ../../dist/include/mozilla/LinkedList.h:258 #6 mozilla::LinkedList<mozilla::image::DiscardTracker::Node>::~LinkedList (this=0xb67cfb44 <mozilla::image::DiscardTracker::sDiscardableImages>, __in_chrg=<optimized out>) at ../../dist/include/mozilla/LinkedList.h:257 #7 0xb74eaec1 in __run_exit_handlers () from /lib/libc.so.6 #8 0xb74eaf4d in exit () from /lib/libc.so.6 #9 0xb74d15ad in __libc_start_main () from /lib/libc.so.6 #10 0x08049eed in _start () at ../sysdeps/i386/elf/start.S:119

Try emptying the list in DiscardTracker::Shutdown(). Or you can do the same thing we did in bug 805207 to the relevant list. I can review either change.

Sorry, I do not know how to do that.

(In reply to :aceman from comment #10) > Sorry, I do not know how to do that. Do you want to learn? In image/src/DiscardTracker.cpp, modify DiscardTracker::Shutdown() so it calls sDiscardableImages.clear(). That's it; just one line.

Wouldn't DiscardAll() be better?

(In reply to :aceman from comment #12) > Wouldn't DiscardAll() be better? That might be fine, yes. This might not fix the problem; we might be getting images added to DiscardTracker after shutdown. In which case we'll have to do something more clever.

Thanks, so both version fix the local crashes for me. So I'll use the DiscardAll version as that seems more semantically correct.

Comment on attachment 678170 [details] [diff] [review] patch Could you please add a comment explaining why this call is necessary? (You might want to add that to the commit message, too, so the commit message better explains why this change fixes the assertion. Multi-line commit messages are OK, if you go that route.) r=me with the comment added.

Any idea why this is not hit by Firefox itself?

Comment on attachment 678173 [details] [diff] [review] patch v2 [Checked in: Comment 17] https://hg.mozilla.org/mozilla-central/rev/2937fd8e35a1

(In reply to :aceman from comment #16) > Created attachment 678173 [details] [diff] [review] > patch v2 [Checked in: Comment 17] > > Any idea why this is not hit by Firefox itself? An image removes itself from this list when it's destructed. So I expect TB may be leaking RasterImages until shutdown in this test. Or maybe it's just not shutting down cleanly.

Thanks for writing the patch!

Seems like we get successful TB debug builds on try after this patch. https://tbpl.mozilla.org/?tree=Thunderbird-Trunk . Ian, please mark this bug as verified if you see the problem fixed. Justin, thanks for your help.