Closed Bug 1682899 Opened 3 years ago Closed 1 year ago

Crash in [@ shutdownhang | NtOpenFile]

Categories

(Core :: Networking: Cache, defect, P2)

Firefox 84
Desktop
Windows 10
defect

Tracking

()

RESOLVED MOVED
Tracking Status
firefox-esr78 --- affected
firefox83 --- affected
firefox84 --- affected

People

(Reporter: u673061, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: crash, Whiteboard: [necko-triaged][necko-monitor])

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/865ff44f-1c26-429b-a797-f6ad10201216

MOZ_CRASH Reason: Shutdown hanging at step profile-change-teardown. Something is blocking the main-thread.

Top 10 frames of crashing thread:

0 ntdll.dll NtOpenFile 
1 kernelbase.dll DeleteFileW 
2 xul.dll nsLocalFile::Remove xpcom/io/nsLocalFileWin.cpp:2154
3 xul.dll nsLocalFile::Remove xpcom/io/nsLocalFileWin.cpp:2146
4 xul.dll mozilla::net::CacheFileIOManager::SyncRemoveDir netwerk/cache2/CacheFileIOManager.cpp:3961
5 xul.dll mozilla::net::CacheFileIOManager::SyncRemoveAllCacheFiles netwerk/cache2/CacheFileIOManager.cpp:3977
6 xul.dll static mozilla::net::CacheFileIOManager::Shutdown netwerk/cache2/CacheFileIOManager.cpp:1190
7 xul.dll mozilla::net::CacheObserver::Observe netwerk/cache2/CacheObserver.cpp:226
8 xul.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:70
9 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:287
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → XPCOM
Product: Firefox → Core

This looks like a shutdown hang while trying to clear the networking cache.

Component: XPCOM → Networking: Cache

This only happens for users that have both privacy.clearOnShutdown.cache and privacy.sanitize.sanitizeOnShutdown set to true.
For a user that has a slow disk, this might be problematic.

An alternative would be to rename the folder and fire an out of process task to remove it instead of removing each file individually.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]

There is still no assignee after 3 months, should we continue on discussing about this bug or close it?

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

There are still crashes happening in Release.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

The bug is linked to a topcrash signature, which matches the following criterion:

  • Top 20 desktop browser crashes on beta

:valentin, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(valentin.gosu)
Keywords: topcrash

We are aiming to land bug 1786256 and bug 1791675 in Firefox 107 and let them ride the trains.
We'll keep these bugs open for further investigation regarding the effectiveness of the fix.

Flags: needinfo?(valentin.gosu)
See Also: → 1790983

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit auto_nag documentation.

Keywords: topcrash

The remaining crashes are all tracked in bug 1809655.

Depends on: 1809655
Whiteboard: [necko-triaged] → [necko-triaged][necko-monitor]

All but two of the crashes have LdrLoadDll on the stack, so I think we can close this bug now.
Bug 1809655 should deal with remaining crashes.

Status: REOPENED → RESOLVED
Closed: 3 years ago1 year ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.