374680 - Assertion failed: hash_table->live_entries == 0 at mozilla/gfx/cairo/cairo/src/cairo-hash.c, line 196

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Bob Clary [:bc] (inactive)]

This assert occurred and an MSCRT Heap error occured on shutdown when running the testcase in attachment 237646 [details] (zip file) in a trunk debug build with Java 6 from this morning.

the stack to the error is:

msvcr80d.dll!_NMSG_WRITE(int rterrnum=10)  Line 198	C

msvcr80d.dll!abort()  Line 59 + 0x7 bytes	C

msvcr80d.dll!_wassert(const wchar_t * expr=0x015135d4, const wchar_t * filename=0x01513548, unsigned int lineno=196)  Line 395	C

thebes.dll!_cairo_hash_table_destroy(_cairo_hash_table * hash_table=0x0404aa80)  Line 196 + 0x1e bytes	C

thebes.dll!_cairo_scaled_font_map_destroy()  Line 251 + 0xb bytes	C

thebes.dll!_cairo_font_reset_static_data()  Line 475	C

thebes.dll!_moz_cairo_debug_reset_static_data()  Line 71	C

thebes.dll!gfxPlatform::~gfxPlatform()  Line 101	C++

thebes.dll!gfxWindowsPlatform::~gfxWindowsPlatform()  Line 66 + 0x43 bytes	C++

thebes.dll!gfxWindowsPlatform::`vector deleting destructor'()  + 0x50 bytes	C++

thebes.dll!gfxPlatform::Shutdown()  Line 90 + 0x23 bytes	C++

gkgfxthebes.dll!nsThebesGfxModuleDtor(nsIModule * self=0x00c45888)  Line 151	C++

...

Comment 1

[Jesse Ruderman]

I'm getting this during shutdown a lot too.  Mac trunk debug.

Comment 2

[Peter Van der Beken [:peterv]]

May be a shutdown ordering issue, seems like the text run cache holds on to gfxFontGroup's which end up holding objects alive that are in the Cairo font map. The text run cache is shut down from nsLayoutStatics::Shutdown, the Cairo font map from gfxPlatform::Shutdown.

Comment 3

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

Makes sense -- I'd been meaning to look into a similar shutdown ordering issue I suspected between gfx and GTK widget.  But I think the solution here may be just to move the shutdown code into ~gfxPlatform.

But I think the thing to do here for a3 is to comment out the call for now; I don't have time to do more before the meeting in 40 minutes...

Comment 4

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

Attachment: comment out cairo_debug_reset_static_data for now

Comment 5

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

Checked in the commenting out; leaving open for better fix.

Comment 6

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

This pushed the Lk number on SeaMonkey nye (Linux) from 2.00MB to 2.32MB.

Comment 7

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

Attachment: revert previous change and make text run cache init/shutdown happen in gfx

Comment 8

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

Roc independently wrote part of the above patch (and more) on bug 375824; the above patch now needs merging (it'll probably be much smaller; perhaps even only reverting the previous change).

Comment 9

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

Backed out previous change; this bug should now be fixed.

Comment 10

[Stuart Parmenter]

I'm seeing this in a build from yesterday morning..  28 entries in the scaled_font hashtable

Comment 11

[Robert Bradbury]

I am seeing this (or a related) bug in the CVS source updated 18 June 2007 (3.0a6pre).

Exact error is:
cairo-hash.c:196: _cairo_hash_table_destroy: Assertion `hash_table->live_entries == 0' failed.
Cairo version is 1.4.6.

It core dumps (aborts) during the firefox exit code (presumably attempting to cleanup the cairo memory allocations).

It can be worked around by compiling /usr/lib/libcairo.* without DEBUG flags (on gentoo the "debug" USE flag) but presumably the mozilla/firefox code should cleanup any use of cairo data structures before exiting.

Comment 12

[Alex Vincent [:WeirdAl]]

Attachment: stack trace

I'm not sure if this matters, but I hit this assertion in Verbosio at shutdown too.

Steps to reproduce are identical to bug 388264 comment 0.

Comment 13

[Priit Laes]

This is actually intended behaviour when Cairo isn't compiled with debug support and there is some dynamic cairo data left when calling it.

From cairo-debug.c:
[snip]
/**
 * cairo_debug_reset_static_data:
 *
 * Resets all static data within cairo to its original state,
 * (ie. identical to the state at the time of program invocation). For
 * example, all caches within cairo will be flushed empty.
 *
 * This function is intended to be useful when using memory-checking
 * tools such as valgrind. When valgrind's memcheck analyzes a
 * cairo-using program without a call to cairo_debug_reset_static_data,
 * it will report all data reachable via cairo's static objects as
 * "still reachable". Calling cairo_debug_reset_static_data just prior
 * to program termination will make it easier to get squeaky clean
 * reports from valgrind.
 *
 * WARNING: It is only safe to call this function when there are no
 * active cairo objects remaining, (ie. the appropriate destroy
 * functions have been called as necessary). If there are active cairo
 * objects, this call is likely to cause a crash, (eg. an assertion
 * failure due to a hash table being destroyed when non-empty).
 **/
[/snip]

So IMHO, the current approach should be either:
   * add some DEBUG_XXX ifdef around the cairo_debug_reset_static_data() call in  gfxPlatform::~gfxPlatform() function
   * or just REMOVE the call...

Comment 14

[Robert Bradbury]

(In reply to comment #13)
> This is actually intended behaviour when Cairo isn't compiled with debug
> support and there is some dynamic cairo data left when calling it.

Fine,  Proper software engineering is that you enter contexts and then exit from them cleanly.  If you make a mess you clean up after yourself.  Firefox does not appear to be able to do that..  And that.I presume is why the error was generated.

Comment 15

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

Actually, it's mostly gtk, gdk, pango, freetype, fontconfig, etc., that don't clean up after themselves (or only do so in "debug-only" functions that aren't actually stable enough for real-world use, especially when you have to decide what order to call all those global shutdown functions in).  Although they do a bit better if we don't let GTK/GDK manage the X display, but do it ourselves -- karlt has a patch to do that.

Comment 16

[Robert Bradbury]

(In reply to comment #15)
> Actually, it's mostly gtk, gdk, pango, freetype, fontconfig, etc., that don't
> clean up after themselves (or only do so in "debug-only" functions that aren't
> actually stable enough for real-world use, especially when you have to decide
> what order to call all those global shutdown functions in).  Although they do a
> bit better if we don't let GTK/GDK manage the X display, but do it ourselves --
> karlt has a patch to do that.
> 
Understood, but why would you want that to be the default state of existence?

One has to be compensating for it in Firefox or on the ground (which might require a whole restructuring of the internet.

Comment 17

[Andrea Rizzolo]

the patch doesnt apply anymore in latest trunk

Comment 18

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

A clean Mac trunk Sunbird debug build outputs the following on shutdown:

Assertion failed at /Users/skywalker/Desktop/Mozilla/cvs/mozilla/gfx/cairo/cairo/src/cairo-hash.c:199: hash_table->live_entries == 0

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Are you building with DEBUG?  The only way that function is called is if:

#if MOZ_TREE_CAIRO && (defined(DEBUG) || defined(NS_BUILD_REFCNT_LOGGING) || defined(NS_TRACE_MALLOC))

Comment 20

[Makoto Kato [:m_kato]]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1267421383.1267423078.4314.gz
OS X 10.5.2 mozilla-central debug test mochitest-other on 2010/02/28 21:29:43

Comment 21

[Matt Woodrow (:mattwoodrow)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274775241.1274776658.5284.gz
WINNT 5.2 mozilla-central debug test mochitests-1/5 on 2010/05/25 01:14:01

Comment 22

[Serge Gautherie (:sgautherie)]

Other examples:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1291397132.1291400869.23106.gz
WINNT 5.2 mozilla-central debug test mochitests-4/5 on 2010/12/03 09:25:32

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1292663890.1292667746.18032.gz
WINNT 5.2 comm-central-trunk debug test mochitests-4/5 on 2010/12/18 01:18:10

Comment 23

[Daniel Holbert [:dholbert]]

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Aurora/1307120191.1307120633.23364.gz
Rev3 Fedora 12 mozilla-aurora debug test crashtest on 2011/06/03 09:56:31

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1311526559.1311527330.6218.gz
Rev3 Fedora 12x64 mozilla-central debug test crashtest on 2011/07/24 09:55:59

Comment 25

[Scott Johnson (:jwir3)]

I believe this has been resolved - tested during graphics bugkill on 7 Oct 2011, with Nightly build: 2011-10-07. Please reopen if this is still an issue.

Comment 26

[Mats Palmgren (inactive)]

It looks like it has occurred again on shutdown after running crashtests:

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137223&tree=Mozilla-Inbound

Rev3 Fedora 12x64 mozilla-inbound debug test crashtest on 2013-01-25 10:42:52 PST for push 308b0c3494ef

slave: talos-r3-fed64-069

firefox-bin: cairo-hash.c:199: _cairo_hash_table_destroy: Assertion `hash_table->live_entries == 0' failed.
TEST-UNEXPECTED-FAIL | Shutdown | Exited with code 6 during test run

Comment 27

[Mats Palmgren (inactive)]

Actually, there were a bunch of them on this particular push.  It seems like
this push was unlucky for some reason -- it doesn't occur in any push after it,
so far...

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137168&tree=Mozilla-Inbound
Rev3 Fedora 12x64 mozilla-inbound debug test mochitest-5 on 2013-01-25 10:42:52 PST for push 308b0c3494ef
slave: talos-r3-fed64-012

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137568&tree=Mozilla-Inbound
Rev3 Fedora 12x64 mozilla-inbound debug test mochitest-other on 2013-01-25 10:43:24 PST for push 308b0c3494ef
slave: talos-r3-fed64-025

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137147&tree=Mozilla-Inbound
Rev3 Fedora 12x64 mozilla-inbound debug test mochitest-4 on 2013-01-25 10:47:16 PST for push 308b0c3494ef
slave: talos-r3-fed64-034

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137405&tree=Mozilla-Inbound
Rev3 Fedora 12x64 mozilla-inbound debug test mochitest-2 on 2013-01-25 10:45:09 PST for push 308b0c3494ef
slave: talos-r3-fed64-011

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137422&tree=Mozilla-Inbound
Rev3 Fedora 12 mozilla-inbound debug test mochitest-2 on 2013-01-25 10:44:50 PST for push 308b0c3494ef
slave: talos-r3-fed-009

https://tbpl.mozilla.org/php/getParsedLog.php?id=19136909&tree=Mozilla-Inbound
Rev3 Fedora 12 mozilla-inbound debug test mochitest-4 on 2013-01-25 10:34:41 PST for push 308b0c3494ef
slave: talos-r3-fed-042

https://tbpl.mozilla.org/php/getParsedLog.php?id=19137110&tree=Mozilla-Inbound
Rev3 Fedora 12 mozilla-inbound debug test jsreftest on 2013-01-25 10:37:13 PST for push 308b0c3494ef
slave: talos-r3-fed-024

Comment 28

[Andrew McCreight [:mccr8]]

There were a bunch of these earlier today on b2g18 that were seemingly fixed by a clobber build, but I guess it could have been some kind of transient infrastructure problem.

Comment 29

[Mats Palmgren (inactive)]

My push only added a bunch of crashtests though, no code changes, so the clobber
theory doesn't seem likely.  I noticed that Linux builds are now named Fedora -
does that imply these are new/upgraded slaves? if so, then it might be a problem
related to the system cairo version?  Otherwise, a "transient infra issue" seems
like a good bet, since they all happened at about the same time on different
slaves / tests.

Comment 30

[u279076]

Mats, is this bug still valid?

Comment 31

[Mats Palmgren (inactive)]

I don't think I've seen this for a while now, so if no one else has either
then we can close this.

Comment 32

[Bob Clary [:bc] (inactive)]

Bughunter doesn't show it any any crashes this year. Fine with WFM.

Comment 33

[u279076]

Thanks guys, closed.