Closed Bug 808379 Opened 7 years ago Closed 7 years ago

Assertion failure: isEmpty(), at ../../dist/include/mozilla/LinkedList.h:258 in mailbloat since landing of fix to bug 803688

Categories

(Core :: ImageLib, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: iann_bugzilla, Assigned: aceman)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Attached patch patch (obsolete) — Splinter Review
Thanks, so both version fix the local crashes for me. So I'll use the DiscardAll version as that seems more semantically correct.
Attachment #678170 - Flags: review?(justin.lebar+bug)
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.
Attachment #678170 - Flags: review?(justin.lebar+bug) → review+
Any idea why this is not hit by Firefox itself?
Assignee: nobody → acelists
Attachment #678170 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #678173 - Flags: review+
Keywords: checkin-needed
Hardware: x86_64 → All
Component: Testing Infrastructure → ImageLib
OS: Linux → All
Product: MailNews Core → Core
Comment on attachment 678173 [details] [diff] [review]
patch v2 [Checked in: Comment 17]

https://hg.mozilla.org/mozilla-central/rev/2937fd8e35a1
Attachment #678173 - Attachment description: patch v2 → patch v2 [Checked in: Comment 17]
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
(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.
You need to log in before you can comment on or make changes to this bug.