Closed
Bug 1219586
Opened 9 years ago
Closed 9 years ago
FireFox 42 repeatedly crashes during exit that takes forever
Categories
(Firefox :: Session Restore, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 816784
People
(Reporter: zxspectrum3579, Unassigned)
References
Details
(Keywords: crash)
Crash Data
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151026170526
Steps to reproduce:
Just normal, but continuous operation where session becomes too slow (due to other known unresolved bugs); I restarted the browser.
Actual results:
Shutting down big session of FireFox takes serious time, but in these cases it takes especially long and results in the same crashes:
https://crash-stats.mozilla.com/report/index/7f27bd33-2aee-4828-afa8-e0ecb2151028
https://crash-stats.mozilla.com/report/index/22fdf697-989e-4fd6-9928-60da72151023
Expected results:
Quick shut down without crash. (Ultimately, FireFox should never require a restart in the first place, but it is different bug.)
Reporter | ||
Updated•9 years ago
|
Crash Signature: shutdownhang | js::NukeCrossCompartmentWrappers
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Reporter | ||
Updated•9 years ago
|
Component: General → DOM
Updated•9 years ago
|
Severity: normal → critical
Crash Signature: shutdownhang | js::NukeCrossCompartmentWrappers → [@ shutdownhang | js::NukeCrossCompartmentWrappers ]
Keywords: crash,
crashreportid
Comment 1•9 years ago
|
||
I can confirm this for x86, it's been happening on my hardware for several months.
Some details:
* an old (2006) laptop with WinXP, <2GB RAM & hardware accelaration unenablable due to the inability to update the drivers.
* when you close a tab in FF, the firefox.exe process seems to unload its content, then 'fatten back' a few MB. When you close the whole window, the unloading has relatively little impact (most tabs are unloaded), but 'fattening back' accumulates to hundreds of MBs. (Recently, the usage seems to drop by several hundred MBs every now and then, but the final result is still a crash much more often than not).
* there are two ways of avoiding the crash (not 100% reliable):
** to open a private window, close the normal one, wait until the memory usage of firefox.exe stabilizes, then close the private window (and wait some time again, because firefox.exe is going to choke a bit here as well),
** to restart instead of closing (at least recently).
The problem is that unloaded tabs still use up some memory (as can be seen in about:memory) instead of being just temporary bookmarks. Cf. bug 945702, bug 1025924, bug 1135214, bug 1159015, bug 1183797 for an analogical issue with the start-up.
Reporter | ||
Comment 2•9 years ago
|
||
Comment 3•9 years ago
|
||
(In reply to User Dderss from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101
> Firefox/42.0
> Build ID: 20151026170526
>
> Steps to reproduce:
>
> Just normal, but continuous operation where session becomes too slow (due to
> other known unresolved bugs); I restarted the browser.
>
>
> Actual results:
>
> Shutting down big session of FireFox takes serious time, but in these cases
> it takes especially long and results in the same crashes:
> https://crash-stats.mozilla.com/report/index/7f27bd33-2aee-4828-afa8-
> e0ecb2151028
> https://crash-stats.mozilla.com/report/index/22fdf697-989e-4fd6-9928-
> 60da72151023
afaict there's nothing terribly interesting here. Do you still see this crash?
Frame Module Signature Source
0 xul.dll mozilla::`anonymous namespace'::RunWatchdog(void*) toolkit/components/terminator/nsTerminator.cpp
1 nss3.dll PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c
2 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c
3 msvcr120.dll _callthreadstartex f:\dd\vctools\crt\crtw32\startup\threadex.c:376
4 msvcr120.dll _threadstartex f:\dd\vctools\crt\crtw32\startup\threadex.c:354
Ø 5 kernel32.dll kernel32.dll@0x15a4c
Ø 6 ntdll.dll ntdll.dll@0x2b830
Ø 7 kernel32.dll kernel32.dll@0x9b82f
Ø 8 kernel32.dll kernel32.dll@0x9b82f
Flags: needinfo?(zxspectrum3579)
Keywords: crashreportid
Component: DOM → Session Restore
Product: Core → Firefox
Reporter | ||
Comment 4•9 years ago
|
||
I have switched to e10s mode, where shutting down goes slow, but still not that slow as in non-e10s where FireFox process gets forcibly terminated just because allowed for shutdown time runs out.
I still do not understand why shutting down has to be slow in the first place, though. FireFox constantly updates its session store object, so there seems to be no reasons at all why FireFox would need to do anything much after user commands exit. Yes, I can understand that certain optimization of session store object might be useful, but if they take so long to perform, then there has to be an option to switch it off, so FireFox could exit *immediately*.
Flags: needinfo?(zxspectrum3579)
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•