16900 - Viewer application sucks up 99% of CPU after quitting.

Status: VERIFIED FIXED

(Core Graveyard :: Viewer App, defect, P3)

Description

[Mo DeJong]

CVS build from 10/18/99. Built on RedHat Linux 5.2 (Intel).

When I quit viewer it does not actually exit the application. It just sits
there sucking up 99% of the CPU. Here is the output that is displayed
when viewer is sucking up 99% of the CPU.


mo(~/project/mozilla/mozilla/dist/bin)% ./viewer
Warning: MOZILLA_FIVE_HOME not set.
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsUnixToolkitService: Using 'gtk' for the Widget Toolkit.
nsUnixToolkitService: Using 'gtk' for the Gfx Toolkit.
NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so,
GFX_DLL=libgfx_gtk.so
Going to create the event queue
GFX: dpi=100 t2p=0.0694444 p2t=14.4 depth=16
Using '/home/mo/project/mozilla/mozilla/dist/bin' as the resource: base
Got the event queue from the service
Calling gdk_input_add with event queue
Note: styleverifytree is disabled
Note: frameverifytree is disabled
Note: verifyreflow is disabled
Going to destroy the event queue


It seems to get getting stuck in a mutex or something.
When I interput it seems to be getting stuck here.


#0  __pthread_mutex_lock (mutex=0x80c8f20) at mutex.c:95
#1  0x401c6b34 in PR_Lock (lock=0x80c8f20) at ptsynch.c:167
#2  0x4017b9a5 in nsAutoLock::nsAutoLock (this=0xbffff2a8, aLock=0x80c8f20)
    at ../../dist/include/nsAutoLock.h:129
#3  0x4012a181 in nsObserverList::RemoveObserver (this=0x80acbd8,
    anObserver=0xbffff384) at nsObserverList.cpp:98
#4  0x4012a9ea in nsObserverService::RemoveObserver (this=0x80b6ec0,
    anObserver=0x80acb9c, aTopic=0xbffff3f8) at nsObserverService.cpp:180
#5  0x40564a25 in nsAppShell::RegisterObserver (this=0x80acb98, aRegister=0)
    at nsAppShell.cpp:491
#6  0x40563c40 in nsAppShell::~nsAppShell (this=0x80acb98, __in_chrg=3)
    at nsAppShell.cpp:143
#7  0x40563d45 in nsAppShell::Release (this=0x80acb98) at nsAppShell.cpp:152
#8  0x4013798c in nsSupportsArray::Clear (this=0x80c9018)
    at nsSupportsArray.cpp:314
#9  0x40136feb in nsSupportsArray::DeleteArray (this=0x80c9018)
    at nsSupportsArray.cpp:58
#10 0x40136d14 in nsSupportsArray::~nsSupportsArray (this=0x80c9018,
    __in_chrg=3) at nsSupportsArray.cpp:35
#11 0x40136ec8 in nsSupportsArray::Release (this=0x80c9018)
    at nsSupportsArray.cpp:54
#12 0x4012a041 in nsObserverList::~nsObserverList (this=0x80acbd8, __in_chrg=3)
    at nsObserverList.cpp:65
#13 0x40129e2e in nsObserverList::Release (this=0x80acbd8)
    at nsObserverList.cpp:36
#14 0x4012a6ce in ReleaseObserverList (aKey=0x80c8f78, aData=0x80acbd8,
    closure=0x0) at nsObserverService.cpp:93
#15 0x4012877c in _hashEnumerateRemove (he=0x80acbf0, i=2, arg=0xbffff670)
    at nsHashtable.cpp:223
#16 0x40198155 in PL_HashTableEnumerateEntries (ht=0x80c7fe8,
    f=0x40128740 <_hashEnumerateRemove(PLHashEntry *, int, void *)>,
    arg=0xbffff670) at plhash.c:368
#17 0x40128812 in nsHashtable::Reset (this=0x80c7fc8,
    destroyFunc=0x4012a6a4 <ReleaseObserverList(nsHashKey *, void *, void *)>,
    closure=0x0) at nsHashtable.cpp:239
#18 0x40128ca2 in nsObjectHashtable::Reset (this=0x80c7fc8)
    at nsHashtable.cpp:361
#19 0x40128b6e in nsObjectHashtable::~nsObjectHashtable (this=0x80c7fc8,
    __in_chrg=3) at nsHashtable.cpp:327
#20 0x4012a545 in nsObserverService::~nsObserverService (this=0x80b6ec0,
    __in_chrg=3) at nsObserverService.cpp:58
#21 0x4012a39a in nsObserverService::Release (this=0x80b6ec0)
    at nsObserverService.cpp:41
#22 0x4015a12c in DeleteEntry (aKey=0x80c7f98, aData=0x80c7f80, closure=0x0)
    at nsServiceManager.cpp:168
#23 0x4012877c in _hashEnumerateRemove (he=0x80c7fb0, i=10, arg=0xbffff76c)
    at nsHashtable.cpp:223
#24 0x40198155 in PL_HashTableEnumerateEntries (ht=0x807c028,
    f=0x40128740 <_hashEnumerateRemove(PLHashEntry *, int, void *)>,
    arg=0xbffff76c) at plhash.c:368
#25 0x40128812 in nsHashtable::Reset (this=0x807c008,
    destroyFunc=0x4015a0f0 <DeleteEntry(nsHashKey *, void *, void *)>,
    closure=0x0) at nsHashtable.cpp:239
#26 0x40128ca2 in nsObjectHashtable::Reset (this=0x807c008)
    at nsHashtable.cpp:361
#27 0x40128b6e in nsObjectHashtable::~nsObjectHashtable (this=0x807c008,
    __in_chrg=3) at nsHashtable.cpp:327
#28 0x4015a288 in nsServiceManagerImpl::~nsServiceManagerImpl (this=0x807bff0,
    __in_chrg=3) at nsServiceManager.cpp:195
#29 0x4015a3ad in nsServiceManagerImpl::Release (this=0x807bff0)
    at nsServiceManager.cpp:204
#30 0x401223eb in NS_ShutdownXPCOM (servMgr=0x0) at nsXPComInit.cpp:478
#31 0x806f174 in main (argc=1, argv=0xbffff824) at nsGtkMain.cpp:191

Comment 1

[rickg]

Kipp -- I'm forwarding this to you since you had posted about the problem. I
expect you know who should *really* own this.

Comment 2

[Warren Harris]

Looks like danm's checkin to widget/src/gtk/nsAppShell.cpp 1.52
      danm%netscape.com
                           Oct 18 08:08

                                       moving Push/PopThreadEventQueue to
nsIEventQueueService. r:[e-mail]

Comment 3

[Dan M]

Yes, I introduced this pretty deadlock. It was fixed yesterday by moving the nsIObserver off nsAppShell.
Strange that a deadlock eats so much CPU time, though.

Comment 4

[Mo DeJong]

I just updated and rebuilt this code, and it is fixed. I am marking
this bug as verified.

Comment 5

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/42626ea34b05
[fenix] 16900 make navgraph inflation asynchronous (https://github.com/mozilla-mobile/fenix/pull/18889)