If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in mozilla19

Status

()

Core
ImageLib
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Ian Neal, Assigned: aceman)

Tracking

Trunk
mozilla19
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

992 bytes, patch
aceman
: review+
Details | Diff | Splinter Review
(Reporter)

Description

5 years ago
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.
(Assignee)

Comment 2

5 years ago
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.
(Reporter)

Comment 3

5 years ago
(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?
(Assignee)

Comment 4

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

Comment 5

5 years ago
(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"
(Assignee)

Comment 6

5 years ago
It does. What next?
Get a backtrace for the MOZ_ASSERT that's failing?
(Assignee)

Comment 8

5 years ago
(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.
(Assignee)

Comment 10

5 years ago
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.
(Assignee)

Comment 12

5 years ago
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.
(Assignee)

Comment 14

5 years ago
Created attachment 678170 [details] [diff] [review]
patch

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+
(Assignee)

Comment 16

5 years ago
Created attachment 678173 [details] [diff] [review]
patch v2 [Checked in: Comment 17]

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+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
Hardware: x86_64 → All
(Reporter)

Updated

5 years ago
Component: Testing Infrastructure → ImageLib
OS: Linux → All
Product: MailNews Core → Core
(Reporter)

Comment 17

5 years ago
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]
(Reporter)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 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!
(Assignee)

Comment 20

5 years ago
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.
Duplicate of this bug: 808320
You need to log in before you can comment on or make changes to this bug.