Got the crash when closing browser after browser-chrome test #0 0x00110402 in __kernel_vsyscall () #1 0x00a5a116 in nanosleep () from /lib/libc.so.6 #2 0x00a59f3f in sleep () from /lib/libc.so.6 #3 0x00137fcb in ah_crap_handler (signum=11) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/toolkit/xre/nsSigHandlers.cpp:149 #4 0x00138c50 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:216 #5 <signal handler called> #6 0x003c774f in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #7 0x00d5004b in g_object_unref () from /lib/libgobject-2.0.so.0 #8 0x0039b2a5 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #9 0x00d500ec in g_object_unref () from /lib/libgobject-2.0.so.0 #10 0x01042f46 in do_gdk_drawable_unref (data=0xaede7080) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/thebes/src/gfxPlatformGtk.cpp:105 #11 0x0104a2aa in _cairo_user_data_array_fini (array=0xae43b8d8) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/cairo/cairo/src/cairo-array.c:378 #12 0x0106281b in *INT__moz_cairo_surface_destroy (surface=0xae43b8c0) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/cairo/cairo/src/cairo-surface.c:442 #13 0x0102ba1b in gfxASurface::Release (this=0xae9999d0) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/thebes/src/gfxASurface.cpp:102 #14 0x07cea8f3 in ~nsThebesImage (this=0xa8cbf6a0) at ../../../dist/include/xpcom/nsAutoPtr.h:956 #15 0x07cea9a3 in nsThebesImage::Release (this=0xa8cbf6a0) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/src/thebes/nsThebesImage.cpp:60 #16 0x07cf1582 in ~nsCOMPtr (this=0xae9c9118) at ../../../dist/include/xpcom/nsCOMPtr.h:525 #17 0x07cf5775 in ~gfxImageFrame (this=0xae9c9100) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/src/shared/gfxImageFrame.cpp:63 #18 0x07cf5a6f in gfxImageFrame::Release (this=0xae9c9100) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/gfx/src/shared/gfxImageFrame.cpp:45 #19 0x002a48c6 in ~nsCOMArray_base (this=0xa8c6cb3c) at nsCOMArray.cpp:61 #20 0x05fb622f in ~imgContainer (this=0xa8c6cb20) at ../../../dist/include/xpcom/nsCOMArray.h:156 #21 0x05fb3394 in imgContainer::Release (this=0xa8c6cb20) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/modules/libpr0n/src/imgContainer.cpp:73 #22 0x05fb6c96 in ~nsCOMPtr (this=0xaed613c8) at ../../../dist/include/xpcom/nsCOMPtr.h:525 #23 0x05fbff61 in ~imgRequest (this=0xaed613a0) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/modules/libpr0n/src/imgRequest.cpp:93 #24 0x05fbf8a7 in imgRequest::Release (this=0xaed613a0) at /home/smaug/mozilla/mozilla_cvs/hg/mozilla/modules/libpr0n/src/imgRequest.cpp:76 #25 0x05fbeaaf in imgCacheEntry::Release (this=0xaf935cd0) at ../../../dist/include/xpcom/nsAutoPtr.h:956 #26 0x05fbee6f in ~nsBaseHashtableET (this=0xaece5318) at ../../../dist/include/xpcom/nsAutoPtr.h:956 #27 0x05fbee90 in nsTHashtable<nsBaseHashtableET<nsCStringHashKey, nsRefPtr<imgCacheEntry> > >::s_ClearEntry ( table=0x5ffb9c0, entry=0xaece5318) at ../../../dist/include/xpcom/nsTHashtable.h:397 ---Type <return> to continue, or q <return> to quit--- #28 0x002a13b9 in PL_DHashTableFinish (table=0x5ffb9c0) at pldhash.c:383 #29 0x05fb8a4e in __tcf_0 () at ../../../dist/include/xpcom/nsTHashtable.h:318 #30 0x009f5c5e in exit () from /lib/libc.so.6 #31 0x009dff78 in __libc_start_main () from /lib/libc.so.6 #32 0x08049221 in _start ()
No idea what's going on here -- it looks like something is holding on to gdk refs possibly beyond when the X Display is closed. Joe, this seems pretty late to be deleting images, is something not getting cleaned up correctly on xpcom shutdown?
Well, we're clearing both caches from imgLoader::Shutdown(), which is called via NS_IMPL_NSGETMODULE_WITH_CTOR_DTOR(nsImageLib2Module, components, imglib_Initialize, imglib_Shutdown) Is that the right way to do it?
Priority: -- → P1
This is really annoying. Whenever running browser-chrome test I must check that I get this crash and not anything else.
Btw, I usually get the crash on 32bit linux, on 64bit I see leaks: TEST-PASS | runtests-leaks | WARNING leaked 936 bytes during test execution TEST-PASS | runtests-leaks | leaked 1 instance of imgCacheEntry with size 48 bytes TEST-PASS | runtests-leaks | leaked 1 instance of imgContainer with size 144 bytes TEST-PASS | runtests-leaks | leaked 1 instance of imgRequest with size 248 bytes TEST-PASS | runtests-leaks | leaked 1 instance of nsPrincipal with size 136 bytes TEST-PASS | runtests-leaks | leaked 1 instance of nsProperties with size 16 bytes TEST-PASS | runtests-leaks | leaked 1 instance of nsSimpleNestedURI with size 128 bytes TEST-PASS | runtests-leaks | leaked 2 instances of nsSimpleURI with size 16 bytes each (32 bytes total) TEST-PASS | runtests-leaks | leaked 9 instances of nsStringBuffer with size 8 bytes each (72 bytes total) TEST-PASS | runtests-leaks | leaked 1 instance of nsSupportsCStringImpl with size 40 bytes TEST-PASS | runtests-leaks | leaked 3 instances of nsTArray_base with size 8 bytes each (24 bytes total) TEST-PASS | runtests-leaks | leaked 2 instances of nsVoidArray with size 8 bytes each (16 bytes total) TEST-PASS | runtests-leaks | leaked 1 instance of nsWeakReference with size 32 bytes
The leak happened also on OSX tbox http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1228300655.1228305461.9710.gz&fulltext=1#err0
Flags: blocking1.9.1- → blocking1.9.1?
Component: GFX: Gtk → ImageLib
OS: Linux → All
QA Contact: gtk → imagelib
Summary: Crash after running browser-chrome test → Crash or leak after running browser-chrome or mochitest
Can you install the gdk debug symbols package to see what's happening inside gdk? I haven't seen this, not sure if Joe has been able to reproduce.
Couldn't find such debug package. Tested with latest trunk, and I still get the crash on 32bit linux debug build.
I see some leaks, but I can't reproduce a crash -- I run the tests using runtests.py --browser-chrome, then close the two windows after test execution (in either order); also tried 'make mochitest-browser-chrome', same result.
Flags: blocking1.9.1? → blocking1.9.1-
Olli, have you seen this crash/leak recently? If not, please close as WFM. Thanks!
I haven't seen this recently.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.