Closed Bug 72864 Opened 24 years ago Closed 24 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: 24 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: 24 years ago → 24 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.