Closed
Bug 709873
Opened 13 years ago
Closed 12 years ago
During ShutdownXPCOM RasterImage::Release does not release OS's Cache when over 4GB.
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 662444
People
(Reporter: rob1weld, Unassigned)
Details
(Keywords: perf, Whiteboard: [has stacktrace])
Attachments
(2 files)
OS's Cache SLOWLY flushing and One Core (of Dual-Core uP) pinned.
On WinXP (32bit) when running Firefox 8 "Release", (and sometimes this occurs with Aurora and Nightly) when you have a lot of Tabs open "Window's Task Manager" may show that your "Page File" (OS's Cache) is greater than 4GB. If you leave Firefox unused for a while (overnight) the Processor may get 'pinned' in the "Window's Task Manager" and you might decide to save your Session, exit Firefox, and restart (to save your place, avoid risk of hanging permanently, and cleanup the Cache). Bug: When you exit Firefox the OS's Cache may take an _extremely_ long time to flush (well over 20 minutes). I attached WinDbg to the Process after ten minutes to see where it was hanging. WinDbg reports some Memory corruption and 'imagelib()' looks like it is hanging here: 0:027> |* ~* kp 0 Id: 13d8.2b3c Suspend: 1 Teb: bffdf000 Unfrozen ChildEBP RetAddr xul!mozilla::imagelib::RasterImage::~RasterImage(void)+0x19c ... xul!mozilla::imagelib::RasterImage::`scalar deleting destructor'(void)+0x8 xul!mozilla::imagelib::RasterImage::Release(void)+0x20 ... xul!imgRequest::~imgRequest(void)+0x15b ... xul!imgRequest::`scalar deleting destructor'(void)+0x8 xul!imgRequest::Release(void)+0x1b ... xul!nsRefPtr<nsCSSStyleSheet>::~nsRefPtr<nsCSSStyleSheet>(void)+0xc ... xul!imgCacheEntry::Release(void)+0x16 ... xul!imgCacheExpirationTracker::NotifyExpired(class imgCacheEntry * entry = 0x1eeaafa0)+0xe1 ... xul!nsExpirationTracker<imgCacheEntry,3>::AgeOneGeneration(void)+0x67 ... xul!nsExpirationTracker<imgCacheEntry,3>::TimerCallback(class nsITimer * aTimer = 0x0108b260, void * aThis = 0x00a1c630)+0xa ... xul!nsTimerImpl::Fire(void)+0xe0 ... xul!nsTimerEvent::Run(void)+0x20 ... xul!nsThread::ProcessNextEvent(int mayWait = <Memory access error>, int * result = <Memory access error>)+0x304 ... xul!NS_ProcessPendingEvents_P(class nsIThread * thread = 0x01e4b7c8, unsigned int timeout = 7)+0x25 ... xul!mozilla::ShutdownXPCOM(class nsIServiceManager * servMgr = 0x00a6c044)+0xa4 ... xul!ScopedXPCOMStartup::~ScopedXPCOMStartup(void)+0x54 ... xul!XRE_main(int argc = 0n1, char ** argv = 0x00a11050, struct nsXREAppData * aAppData = 0x00a14440)+0xe5d ... firefox!wmain(int argc = <Memory access error>, wchar_t ** argv = <Memory access error>)+0x812 ... firefox!__tmainCRTStartup(void)+0x152 ... kernel32!BaseProcessStart+0x23 Firefox is NOT releasing the OS's Cache at a reasonable rate (see attached Screenshot of "Window's Task Manager") and it maybe that "xul!mozilla::imagelib::RasterImage::Release()" is not releasing the Memory; possible due to Memory corruption of the Pointers (see attached WinDbg Log).
|
||
Comment 2•12 years ago
|
||
(In reply to Rob from comment #0) > Created attachment 580969 [details] > WinDbg Log created by using "Attach to a Process", of Nightly failing to > exit in a timely manner. does not constitute critical > On WinXP (32bit) when running Firefox 8 "Release", (and sometimes this > occurs with Aurora and Nightly) when you have a lot of Tabs open "Window's > Task Manager" may show that your "Page File" (OS's Cache) is greater than > 4GB. > > If you leave Firefox unused for a while (overnight) the Processor may get > 'pinned' in the "Window's Task Manager" and you might decide to save your > Session, exit Firefox, and restart (to save your place, avoid risk of > hanging permanently, and cleanup the Cache). testcase/details to reproduce? > Bug: > When you exit Firefox the OS's Cache may take an _extremely_ long time to > flush (well over 20 minutes). > > I attached WinDbg to the Process after ten minutes to see where it was > hanging. > > > WinDbg reports some Memory corruption and 'imagelib()' looks like it is > hanging here: > > 0:027> |* ~* kp > > 0 Id: 13d8.2b3c Suspend: 1 Teb: bffdf000 Unfrozen > ChildEBP RetAddr > xul!mozilla::imagelib::RasterImage::~RasterImage(void)+0x19c ... > xul!mozilla::imagelib::RasterImage::`scalar deleting destructor'(void)+0x8 > xul!mozilla::imagelib::RasterImage::Release(void)+0x20 ... > xul!imgRequest::~imgRequest(void)+0x15b ... > xul!imgRequest::`scalar deleting destructor'(void)+0x8 > xul!imgRequest::Release(void)+0x1b ... > xul!nsRefPtr<nsCSSStyleSheet>::~nsRefPtr<nsCSSStyleSheet>(void)+0xc ... > xul!imgCacheEntry::Release(void)+0x16 ... > xul!imgCacheExpirationTracker::NotifyExpired(class imgCacheEntry * entry = > 0x1eeaafa0)+0xe1 ... > xul!nsExpirationTracker<imgCacheEntry,3>::AgeOneGeneration(void)+0x67 ... > xul!nsExpirationTracker<imgCacheEntry,3>::TimerCallback(class nsITimer * > aTimer = 0x0108b260, void * aThis = 0x00a1c630)+0xa ... > xul!nsTimerImpl::Fire(void)+0xe0 ... > xul!nsTimerEvent::Run(void)+0x20 ... > xul!nsThread::ProcessNextEvent(int mayWait = <Memory access error>, int * > result = <Memory access error>)+0x304 ... > xul!NS_ProcessPendingEvents_P(class nsIThread * thread = 0x01e4b7c8, > unsigned int timeout = 7)+0x25 ... > xul!mozilla::ShutdownXPCOM(class nsIServiceManager * servMgr = > 0x00a6c044)+0xa4 ... > xul!ScopedXPCOMStartup::~ScopedXPCOMStartup(void)+0x54 ... > xul!XRE_main(int argc = 0n1, char ** argv = 0x00a11050, struct nsXREAppData > * aAppData = 0x00a14440)+0xe5d ... > firefox!wmain(int argc = <Memory access error>, wchar_t ** argv = <Memory > access error>)+0x812 ... > firefox!__tmainCRTStartup(void)+0x152 ... > kernel32!BaseProcessStart+0x23 > > > Firefox is NOT releasing the OS's Cache at a reasonable rate (see attached > Screenshot of "Window's Task Manager") and it maybe that > "xul!mozilla::imagelib::RasterImage::Release()" is not releasing the Memory; > possible due to Memory corruption of the Pointers (see attached WinDbg Log).
(In reply to Wayne Mery (:wsmwk) from comment #2) > (In reply to Rob from comment #0) > > Created attachment 580969 [details] > > WinDbg Log created by using "Attach to a Process", of Nightly failing to > > exit in a timely manner. > > does not constitute critical I thought it "critical" to the "operation of the Computer" that Firefox interferes severely with the Computer (and restarting Firefox itself) along with the severity of the incorrect operation of memory allocation would place it in that category -- I am OK with "major". > > On WinXP (32bit) when running Firefox 8 "Release", (and sometimes this > > occurs with Aurora and Nightly) when you have a lot of Tabs open "Window's > > Task Manager" may show that your "Page File" (OS's Cache) is greater than > > 4GB. > > > > If you leave Firefox unused for a while (overnight) the Processor may get > > 'pinned' in the "Window's Task Manager" and you might decide to save your > > Session, exit Firefox, and restart (to save your place, avoid risk of > > hanging permanently, and cleanup the Cache). > > testcase/details to reproduce? Simply keep opening Tabs (or save your Sessions over a period of weeks and add new Tabs as you go) until you exceed 2GB (closer to 4GB is better) and you get to the "past the 2GB Memory Bug" where memory allocation operates incorrectly. It is speculative for me to suggest that there is a fault with allocating over 2GB similar to the 2TB limit for HDs under WinXP (under certain circumstances) but that is a similar sort of example. You do not need a particular list of 300+ Tabs, simply try to get close to allocating 4GB of memory on WinXP. You get to a point where FF will not use Virtual Memory (swap drive) when it needs more memory, the Processor will pin and you may get screen of menu corruption. This seems to have not happened in that past month but prior to that it seemed to occur more or less rarely. It may now occur so rarely that it is hard to say if it will ever reoccur or if it is truly fixed. I will close this in a couple of months if it does not happen during that time. I believe I was accurate in determining the location of the fault (imagelib). > > Bug: > > When you exit Firefox the OS's Cache may take an _extremely_ long time to > > flush (well over 20 minutes). > > > > I attached WinDbg to the Process after ten minutes to see where it was > > hanging. > > > > > > WinDbg reports some Memory corruption and 'imagelib()' looks like it is > > hanging here: > > > > 0:027> |* ~* kp > > > > 0 Id: 13d8.2b3c Suspend: 1 Teb: bffdf000 Unfrozen > > ChildEBP RetAddr > > xul!mozilla::imagelib::RasterImage::~RasterImage(void)+0x19c ... > > xul!mozilla::imagelib::RasterImage::`scalar deleting destructor'(void)+0x8 > > xul!mozilla::imagelib::RasterImage::Release(void)+0x20 ... > > xul!imgRequest::~imgRequest(void)+0x15b ... > > xul!imgRequest::`scalar deleting destructor'(void)+0x8 > > xul!imgRequest::Release(void)+0x1b ... > > xul!nsRefPtr<nsCSSStyleSheet>::~nsRefPtr<nsCSSStyleSheet>(void)+0xc ... > > xul!imgCacheEntry::Release(void)+0x16 ... > > xul!imgCacheExpirationTracker::NotifyExpired(class imgCacheEntry * entry = > > 0x1eeaafa0)+0xe1 ... > > xul!nsExpirationTracker<imgCacheEntry,3>::AgeOneGeneration(void)+0x67 ... > > xul!nsExpirationTracker<imgCacheEntry,3>::TimerCallback(class nsITimer * > > aTimer = 0x0108b260, void * aThis = 0x00a1c630)+0xa ... > > xul!nsTimerImpl::Fire(void)+0xe0 ... > > xul!nsTimerEvent::Run(void)+0x20 ... > > xul!nsThread::ProcessNextEvent(int mayWait = <Memory access error>, int * > > result = <Memory access error>)+0x304 ... > > xul!NS_ProcessPendingEvents_P(class nsIThread * thread = 0x01e4b7c8, > > unsigned int timeout = 7)+0x25 ... > > xul!mozilla::ShutdownXPCOM(class nsIServiceManager * servMgr = > > 0x00a6c044)+0xa4 ... > > xul!ScopedXPCOMStartup::~ScopedXPCOMStartup(void)+0x54 ... > > xul!XRE_main(int argc = 0n1, char ** argv = 0x00a11050, struct nsXREAppData > > * aAppData = 0x00a14440)+0xe5d ... > > firefox!wmain(int argc = <Memory access error>, wchar_t ** argv = <Memory > > access error>)+0x812 ... > > firefox!__tmainCRTStartup(void)+0x152 ... > > kernel32!BaseProcessStart+0x23 > > > > > > Firefox is NOT releasing the OS's Cache at a reasonable rate (see attached > > Screenshot of "Window's Task Manager") and it maybe that > > "xul!mozilla::imagelib::RasterImage::Release()" is not releasing the Memory; > > possible due to Memory corruption of the Pointers (see attached WinDbg Log).
|
||
Comment 4•12 years ago
|
||
There's nothing we can do if freeing memory takes a long time. More than likely, Windows has swapped out parts of Firefox's working set that need to be swapped in from disk (incredibly slow!) before they can be freed. This will be fixed when we exit immediately rather than closing everything up.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
(In reply to Joe Drew (:JOEDREW!) from comment #4) > There's nothing we can do if freeing memory takes a long time. More than > likely, Windows has swapped out parts of Firefox's working set that need to > be swapped in from disk (incredibly slow!) before they can be freed. > > This will be fixed when we exit immediately rather than closing everything > up. > > *** This bug has been marked as a duplicate of bug 662444 *** Agreed that duping this to Bug 662444 would resolve my complaint. Thanks.
No longer blocks: 702012
You need to log in
before you can comment on or make changes to this bug.
Description
•