Crash or leak after running browser-chrome or mochitest

RESOLVED WORKSFORME

Status

()

Core
ImageLib
P1
critical
RESOLVED WORKSFORME
10 years ago
2 years ago

People

(Reporter: smaug, Unassigned)

Tracking

Trunk
x86
All
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

10 years ago
Flags: blocking1.9.1?
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?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P1
(Reporter)

Comment 3

10 years ago
This is really annoying. Whenever running browser-chrome test I must check that
I get this crash and not anything else.
(Reporter)

Comment 4

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

Updated

10 years ago
Severity: normal → critical
(Reporter)

Comment 6

10 years ago
Reasking blocking1.9.1?
Flags: blocking1.9.1- → blocking1.9.1?
(Reporter)

Updated

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

Comment 8

10 years ago
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!
Flags: needinfo?(bugs)
(Reporter)

Comment 11

2 years ago
I haven't seen this recently.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(bugs)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.