Closed Bug 72864 Opened 23 years ago Closed 23 years ago

[new cache] OnFileAvailable called before file is available - busts plugins

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 72973

People

(Reporter: sean, Assigned: beard)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [cache]) 

I did a pull yesterday morning and did a build with MOZ_NEW_CACHE=1.
Plugins that use nsPluginStreamType_AsFile or nsPluginStreamType_AsFileOnly 
fail to work properly with the new cache.  
nsPluginStreamListenerPeer::OnStopRequest in nsPluginHostImpl.cpp successfully 
gets the filename of the cache entry (in order to call the plugin's 
OnFileAvailable), and the file on disk exists, but it's size is 0.  The plugin 
fails to load in the requested url on the first attempt.  Refreshing the page 
works once the file has been written to disk.
-->gordon
Assignee: neeti → gordon
*** Bug 73084 has been marked as a duplicate of this bug. ***
Keywords: regression
*** Bug 72903 has been marked as a duplicate of this bug. ***
reassign to me to look at.
Assignee: gordon → dougt
new cache is not being build right on windows.  Fix was checked in at 2001/03/23 
03:08:59;  Tomorrows build should have this fix.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Same results with fresh pull this morning.  Problem is the same: the requested 
file is not written to disk before OnFileAvailable is called.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
darin, you mentioned that the builds on mozilla are not being updated.  Is this
still the case?  

If I build mozilla myself, plugins work fine.
wait, you said you did a fresh pull... hmm.
Are you using Acrobat as a testcase?  Also- make sure you clear the cache 
before you test.
yes, I am using a pdf.  And the cache is cleared.  Could you set a breakpoint on
the nsPluginStreamListenerPeer::OnStartRequest and trace into the call to
SetCacheAsFile()?  Is there any error or failing assertion?


Patrick, is there any chance that you are not flushing to disk by the time
onStopRequest is called?
Setting a breakpoint on SetCacheAsFile, I go all the way into SetStoragePolicy -
 no errors or assertions.  Maybe this is only on Win2K or NTFS5 - what OS and 
filesystem are you testing on?

I'm not able to tell at what point the cached file goes from 0 to the right 
size, but it's sometime after OnFileAvailable is called and before the page 
finishes loading.
Whiteboard: [cache]
I just ran file monitor and saw that:
1. when OnFileAvailable is called, the file can't be opened by my plugin due to 
a sharing violation.
2. The contents of the file are not written out until after OnFileAvailable is 
called.

If you open a full page plugin, the filesize is still 0 when the wallet service 
assertion fires (which happens after OnFileAvailable is called).

Although I did a pull this morning, it was a depend build.  If Doug was seeing 
this yesterday and not today, then maybe I should do a clobber build?

I am assigning this to beard.  Can this file be closed by you when we call
GetCachedFile?
Assignee: dougt → beard
Status: REOPENED → NEW
I believe this may be HTTP's fault b/c it does not close it's cache output
stream until after calling OnStopRequest.  This is a major problem, resulting
in more than just this bug!  I'm working on a fix, but it will take some time
before it is ready.
Thanks for the info darin. I will wait to here more from you on this.s
This is happening for me too. Windows 2000 Pro/Server.
i'm guessing that this depends on my fix for bug 72973.

peter: can you verify whether or not my patch:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28768
fixes the problem?  thanks!
Depends on: 72973
Beatnik Player is much happier with 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28768.
Thanks Darin!

sweet!  thanks darin.  sr=dougt.  lets get it in today! :-)
I think this is blocking me as well and I see what Sean describes. On the Mac, 
how to do you build with MOZ_NEW_CACHE=0?

Oh hell, I'll just pull tonight and re-build if the fix is in today.
Blocks: 38484
per sean's comments: marking as a dupe of bug 72973, and checking in fix.

*** This bug has been marked as a duplicate of 72973 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Wait...this patch alone doesn't fix the problem. Darin, have you tried the pdf 
above and those at http://slip/shrir?

I am updating netwerk in my tree now to try that.
i have not verified that my patch to bug 72973 fixes this... i was just working
off of sean's comments.  please reopen and un-dupe if appropriate.  sorry!
Actually, I just got it to work with a new profile but then crashed somewhere 
else. All on Win32. I'm updating my whole tree right now, maybe that will fix 
the problem. I'm leaving this along till QA can verify tomorrow with stable 
builds.

However, how do I set my Mac build to use the old cache while I'm working on 
bugs (MOZ_NEW_CACHE=0)?
peterl: talk to patrick beard or gordon sheridan for exact details about mac
builds, but if i recall, there is an "options cache" someplace.  you can
toggle this flag to make HTTP use the old cache.
Just for the record - I did test the patch with the Acrobat testcase in the url.
You need to log in before you can comment on or make changes to this bug.