Last Comment Bug 856743 - CachedFileHolder::Release does I/O on the main thread
: CachedFileHolder::Release does I/O on the main thread
Status: NEW
: main-thread-io
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 22 Branch
: All All
P3 normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Benjamin Smedberg [:bsmedberg]
Depends on:
  Show dependency treegraph
Reported: 2013-04-01 11:49 PDT by Vladan Djeric (:vladan)
Modified: 2014-05-13 16:00 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Reinstate Node.hasAttributes. (113.33 KB, patch)
2013-04-01 11:53 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review

Description User image Vladan Djeric (:vladan) 2013-04-01 11:49:38 PDT
I got a 3-second main thread hang on Windows with the following stack. I think I triggered it by closing a YouTube tab. 
Would it be possible to do the file remove off the main thread, perhaps using OS.File?

NtClose (in wntdll.pdb)
nsLocalFile::Remove(bool) (in xul.pdb)
CachedFileHolder::~CachedFileHolder() (in xul.pdb)
CachedFileHolder::`scalar deleting destructor'(unsigned int) (in xul.pdb)
CachedFileHolder::Release() (in xul.pdb)
nsRefPtr<CachedFileHolder>::~nsRefPtr<CachedFileHolder>() (in xul.pdb)
nsPluginStreamListenerPeer::~nsPluginStreamListenerPeer() (in xul.pdb)
nsPluginStreamListenerPeer::`vector deleting destructor'(unsigned int) (in xul.pdb)
nsPluginStreamListenerPeer::Release() (in xul.pdb)
DoDeferredRelease<nsISupports *> (in xul.pdb)
XPCJSRuntime::GCCallback(JSRuntime *,JSGCStatus) (in xul.pdb)
Collect (in mozjs.pdb)
js::GCSlice(JSRuntime *,js::JSGCInvocationKind,JS::gcreason::Reason,__int64) (in mozjs.pdb)
js_InvokeOperationCallback(JSContext *) (in mozjs.pdb)
js_HandleExecutionInterrupt(JSContext *) (in mozjs.pdb)
js::mjit::stubs::Interrupt(js::VMFrame &,unsigned char *) (in mozjs.pdb)

From a source comment:

"When a plugin requests opens multiple requests to the same URL and the request must be satified by saving a file to disk, each stream listener holds a reference to the backing file: the file is only removed when all the listeners are done."
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2013-04-01 11:53:52 PDT
Created attachment 731969 [details] [diff] [review]
Reinstate Node.hasAttributes.
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2013-04-01 12:15:20 PDT
Comment on attachment 731969 [details] [diff] [review]
Reinstate Node.hasAttributes.

Bugzilla db corruption clobbered the original bug 856743 after I filed it but before I wrote this patch... :(
Comment 3 User image Georg Fritzsche [:gfritzsche] 2013-04-03 06:16:18 PDT
(In reply to Vladan Djeric (:vladan) from comment #0)
> Would it be possible to do the file remove off the main thread, perhaps
> using OS.File?

Lookup of the cached files is via existing peers in nsPluginStreamListenerPeer::SetupPluginCacheFile() and falls back to creating a new file with CreateUnique().
So this seems safe to me.

Note You need to log in before you can comment on or make changes to this bug.